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V 


Experiment  Transcripts  for  the  Evaiuation  of  the 
Rationai  Environment 


Abstract:  This  report  supplements  the  SEI  report  Evaluation  of  the  Rational 
Environment  (CMU/SEI-88-TR-15)  by  Peter  Feiler,  Susan  Dart,  and  Grace  Downey.  It 
contains  the  instantiation  of  the  experiments  presented  in  the  Evaluation  of  Ada 
Environments  by  Nelson  Weiderman,  et  al.  (see  [7]).  Overall  conclusions  and  analysis 
of  the  Rational  Environment  can  be  found  in  Evaluation  of  the  Rational  Environment 


1.  Introduction 
1.1.  Scope 

The  evaluation  of  the  Rational  Environment  and  R1 000  computer  was  initially  conducted  by  Com¬ 
puter  Sdences  Corporation  (CSC)  using  the  Gamma  Release  of  the  Rational  Environment.  Au¬ 
thors  of  an  internal  CSC  report  released  in  January  of  1987  were  Mitchell  J.  Bassman  and  Carl 
Dahike  (see  [3]).  The  instantiation  of  the  experiments  on  the  Gamma  Release  of  the  Rational 
Environment  were  written  and  performed  by  Carl  Dahike,  Diane  E.  Odiorne,  and  Katherine 
E.  Stanton  at  CSC's  Star*  Lab.  This  report  contains  the  results  of  repeating  the  experiments  on 
the  Delta  Release  of  the  Rational  Environment  at  the  Software  Engineering  Institute  (SEI).  The 
Delta  Release  of  the  Rational  Environment  provides  the  initial  release  of  configuration  manage¬ 
ment  and  version  control  tools.  This  report  contains  the  results  of  instantiating  the  Configuration 
Management/Version  Control  Experiments  from  the  Evaluation  of  Ada  Environments.  Grace 
Downey  repeated  the  experiments  according  to  the  CSC  transcripts,  adjusted  the  transcripts  for 
the  Delta  Release,  and  instantiated  and  performed  the  Configuration  Management/Version  Con¬ 
trol  Experiments.  Analysis  of  the  Rational  Environment  and  analysis  of  the  experiment  results  are 
provided  by  Peter  Feiler,  Susan  Dart  and  Grace  Downey  In  Evaluation  of  the  Rational 
Environment  (SEI-88-TR-1 5). 


1.2.  Evaluation  Experiments  Performed 

Of  the  six  categories  of  experiments  presented  in  the  Evaluation  Method,  five  were  performed  on 
the  Delta  Release  of  the  Rational  Environment.  A  brief  description  of  each  experiment  follows. 

1.2.1.  Configuration  ManagemenWersion  Controi  Experiments 

This  group  of  experiments  provides  an  evaluation  of  an  environment’s  version  control  capabilities 
(i.e.,  support  of  successive  versions,  variant  versions,  file  checkin/checkout,  etc.)  as  well  as  its 
configuration  management  capabilities  (i.e.,  support  of  system  construction  and  reconstruction, 
baselining,  release  management,  history  collection,  etc.).  The  first  of  three  experiments  simu¬ 
lates  the  system  integration  and  testing  phase  of  the  software  development  cycle.  The  second 
experiment  assumes  the  first  has  been  conducted  and  investigates  system  construction, 
reconstruction  of  previously  baselined  systems,  and  a  combination  of  elements  from  old  and  new 
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systems.  Chapter  2  contains  the  instantiation  of  the  first  two  experiments.  The  third  experiment 
investigates  software  management  activities,  including  release  control  and  release  history.  Ra¬ 
tional  expects  the  user  to  tailor  commands  from  work  order,  configuration  management,  and 
version  control  commands  to  enforce  a  software  management  policy.  The  third  experiment  was 
not  performed  because  it  does  not  specify  a  software  management  policy  nor  does  the  Rational 
Environment  dictate  one. 

1.2.2.  System  Management  Experiments 

Four  aspects  of  system  management  are  separately  evaluated:  Ada  Programming  Support  Envi¬ 
ronment  (APSE)  installation,  user  account  management,  environment  maintenance  and  support 
for  machine  usage  accounting. 

Rational  technicians  perform  all  APSE  installation  and  updating,  and  the  procedures  used  are  not 
described  in  the  documentation  for  system  managers;  therefore,  the  APSE  installation  experiment 
was  not  performed. 

User  account  management  is  largely  concerned  with  controlling  access  to  user  accounts.  The 
Gamma  Release  of  the  Rational  Environment  did  not  provide  any  access  control  capabilities 
except  for  requiring  an  operator  password  to  execute  certain  environment  commands.  The  Delta 
Release,  however,  does  provide  access  control  functionality.  Therefore,  the  experiment  was 
re-instantiated  and  includes  the  steps  which  exercise  the  access  control  facilities. 

The  environment  maintenance  experiment  consists  of  a  series  of  questions,  which  were  an¬ 
swered. 

Little  of  the  Environment  Maintenance  and  Support  for  the  Machine  Usage  Accounting  Exper¬ 
iment  had  to  be  instantiated  for  the  Rational  Environment,  as  most  of  the  functionality  requested 
already  exists  in  commands  provided  by  the  Environment.  The  experiment  is  presented  through 
descriptions  of  how  to  access  and  use  the  environment-supplied  accounting  information. 

1.2.3.  Design  and  Development  Experiment 

The  Rational  Environment  provides  most  of  the  capabilities  evaluated  by  the  design  and  devel¬ 
opment  experiment  category.  Some  steps  of  the  experiment  were  omitted  because  the  Rational 
Environment  does  not  supply  any  graphical  design  interface  tools.  The  experiment  consists  of 
developing  a  small  system  consisting  of  several  Ada  units.  Creating  procedures  and  packages, 
compiling,  and  changing  the  procedures  and  packages  constitute  many  of  the  steps  of  the  exper¬ 
iment. 

1.2.4.  Unit  Testing  and  Debugging  Experiment 

The  Rational  Environment  provides  most  capabilities  evaluated  by  the  Unit  Test  and  Debug  Ex¬ 
periment  category.  Again,  some  steps  of  the  experiment  were  omitted  because  the  Rational 
Environment  provides  no  supported  static  or  dynamic  analysis  tools.  The  experiment  consists  of 
testing  a  small  system  of  Ada  units,  debugging  and  changing  the  units,  and  regression  testing. 
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1.2.5.  The  Project  Management  Experiment 

The  Project  Management  Experiment  (see  [5]),  by  Peter  H.  Feiler  and  Roger  Smeaton,  evaluates 
an  environment’s  ability  to  support  four  categories  of  project  management:  project  plan  manage¬ 
ment,  plan  instantiation,  project  execution,  and  product  management.  The  level  of  support  that 
the  Rational  Environment  provides  in  these  areas  is  tested  in  the  Configuration 
ManagementA/ersion  Control  Experiments:  hence,  this  experiment  is  not  instantiated  for  the  Ra¬ 
tional  Environment. 

1.2.6.  Prototype  Ada  Compiler  Evaluation  Capability  (ACEC) 

The  prototype  Ada  Compiler  Evaluation  Capability  (ACEC)  test  suite  was  run  on  the  Rational 
Environment.  The  Institute  for  Defense  Analysis  (IDA)  developed  the  test  suite  from  public 
domain  software,  and  the  suite  and  its  use  is  described  in  IDA  PAPER  P-1879,  User's  Manual  for 
the  Prototype  Ada  Compiler  Evaluation  Capability  (ACEC)  Version  1,  by  Audrey  A.  Hook,  Gregory 
A.  Riccardi,  Michael  Vilot,  and  Stephen  Welke  (see  [1]).  Numeric  results  from  running  the  ACEC 
suite,  problems  with  the  suite  detected  by  the  Rational  Environment,  and  some  tailoring  required 
for  the  Rational  Erwironment  are  reported. 

1 .2.7.  Appendices 

The  appendices  to  this  document  consist  of  code  developed  specifically  for  the  Rational  Environ¬ 
ment  to  perform  measurements  for  some  of  the  experiments.  The  Prototype  ACEC  suite  requires 
that  some  environment-spedfic  code  be  developed;  this  is  presented  as  well. 


1.3.  Environment  Version  and  Hardware  Evaluated 

The  evaluation  of  the  Rational  Environment  was  performed  with  the  following  hardware  configu¬ 
ration  and  software  configuration.  The  hardware  configuration  is  a  R1000  Model  200-20  with  the 
following  components: 

•  32  Mb  of  primary  memory. 

•  Approximately  2,01 0  Mb  of  unformatted  disk  storage  (3  disks  with  approximately  670 
Mb  capacity  each). 

•  Tape  drive  PE/GCR  75  ips  streaming  tape. 

•  Ethernet  connection. 

•  8  Rational  terminals  connected  to  the  R1000  over  the  Ethernet  via  a  DECserver. 

The  software  configuration  is  release  D_9_25_1  or  DeltaO  of  the  Rational  Environment.  The 
environment  evaluated  was  the  base  environment,  which  comes  as  one  package  and  includes 
the  following: 

•  Basic  operating  system  functionality,  such  as  file  and  directory  system,  process  man¬ 
agement,  access  control,  etc. 

•  A  tiled  window  system  for  character  terminals. 

•  An  Ada  command  processor. 

•  An  editor  and  browser  sensitive  to  Ada  syntax  and  semantics. 
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•  An  incremental  Ada  compilation  system. 

•  A  debugging  system  with  extensive  coverage  of  the  Ada  language. 

•  Programming-in-the-large  support  in  the  form  of  the  subsystem  concept. 

•  Configuration  management  and  version  control  support. 

•  Workorder  management  support. 

Unsupported  tools  contributed  by  users  include  a  reusable  component  library,  metric  collection 
tools,  and  browsing  tools.  These  packages  were  not  included  in  the  evaluated  environment 
because  they  either  are  unsupported  tools  or  they  were  not  available  to  the  evaluators  at  the  time 
of  evaluation. 

1.4.  Report  Structure 

Chapters  2  through  6  each  represent  one  experiment  category  of  the  SEI  evaluation  method  as  it 
was  performed  on  the  Rational  Environment. 

•  Chapter  2  -  Configuration  ManagementA/ersion  Control  Experiments 

•  Chapter  3  -  System  Management  Experiments 

•  Chapter  4  -  Design  and  Development  Experiments 

•  Chapter  5  -  Unit  Testing  and  Debugging  Experiments 

•  Chapter  6  -  Prototype  ACEC 

An  introduction  in  each  chapter  outlines  the  experiment  and  explains  the  notation  used  in  the 
experiment  transcripts.  Some  categories  contain  multiple  experiments.  The  experiment 
transcripts  are  then  presented,  followed  by  a  checklist  summarizing  the  functionality  provided  or 
not  provided  by  the  Rational  Environment.  Questions  associated  with  each  of  the  experiments 
are  answered.  A  brief  conclusion  to  each  experiment  discusses  the  Environment’s  capabilities  in 
terms  of  functionality,  performance,  user  interface,  and  system  interface.  Any  problems  encoun¬ 
tered  in  instantiating  the  experiment  are  discussed  in  the  functionality  subsections  of  these  con¬ 
clusions. 

Previous  SEI  environment  evaluations  included  command  files  that  instantiate  the  experiments. 
Because  the  Rational  Environment  is  intended  for  use  as  an  interactive  environment,  each  exper¬ 
iment  step  is  listed,  followed  by  a  "script"  of  Rational  commands  necessary  to  perform  the  step. 
The  transcripts  of  the  Configuration  ManagementA/ersion  Control  Experiments  and  System  Man¬ 
agement  Experiments  explore  the  Environment  commands  more  closely  by  detailing  the 
commands'  program  interface.  The  transcripts  of  the  Design  and  Development  and  Unit  Testing 
and  Debugging  Experiments  are  more  terse  because  many  of  the  Environment  commands  are 
bound  to  program  function  keys.  In  order  to  provide  a  better  flavor  of  how  the  Environment  can 
be  used  interactively,  actual  keystrokes  are  shown,  rather  than  the  program  interface  bound  to 
the  keys. 

The  final  chapter  contains  a  cross-environment  comparison  of  the  Rational  Environment  and 
previously  evaluated  Environments  in  terms  of  performance  figures. 
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2.  Configuration  ManagementA/ersion  Control 
Experiments 

The  Configuration  Management/Version  Control  (CMA/C)  Experiments  exercise  the  version  con¬ 
trol  capabilities  of  the  Environment.  The  first  experiment  simulates  the  system  integration  and 
testing  phase  of  the  life  cycle  by  having  three  separate  development  lines  of  descent  from  a 
single  baselined  system.  The  second  experiment  investigates  the  Environment’s  support  for 
activities  such  as  system  construction,  reconstruction  of  previously  generated  baselined  systems, 
and  the  construction  of  a  mixture  of  new  and  old  systems. 

The  third  experiment  in  the  area  of  configuration  management  investigates  the  activities  involved 
in  the  management  of  a  software  product,  including  release  control  and  release  history.  Although 
the  Rational  Environment  provides  the  capability  to  track  release  control  and  release  history 
through  the  work  order  management  package,  this  package  represents  a  primitive  set  of  com¬ 
mands.  Rational  expects  the  user  to  construct  a  series  of  "skins"  which  invoke  the  work  order 
commands,  and  to  some  extent  the  configuration  management  commands  to  enforce  company 
policy.  No  "company  policy"  is  presented  in  the  third  experiment,  and  for  this  reason  the  exper¬ 
iment  is  not  instantiated.  For  a  discussion  of  the  work  order  management  package,  see 
Evaluation  of  the  Rational  Environment  (see  [4]). 

The  system  described  by  the  experiment  is  broken  into  three  subsystems:  VT,  CLI,  and  SM.  The 
subsystem  boundary  described  by  the  experiment  could  have  been  ignored,  and  all  units  placed 
in  one  large  subsystem.  The  functionality  tested  by  the  experiment  would  have  been  easily 
covered  by  the  CMA/C  facilities  in  the  Environment.  To  more  fully  exercise  the  CM/VC  package, 
the  three  experiment  subsystems  were  instantiated  as  Rational  Environment  subsystems.  A 
main  program  that  depends  on  Ada  units  in  each  of  the  three  systems  is  also  provided,  and  acts 
as  a  subsystem  driver  through  the  course  of  the  first  experiment.  To  make  use  of  more  features 
provided  by  configuration  management  and  version  control  packages  in  the  Delta  Release,  the 
main  program  was  placed  in  a  fourth  subsystem,  MAIN. 

Yet  a  fifth  subsystem,  AS,  was  required  to  instantiate  the  experiment  due  to  a  bug  in  the 
Cmvc.Release  command.  A  package  specification  in  SM  depends  upon  two  packages  contained 
in  the  subsystem  CLI.  A  separate  subunit  in  CLI  depends  upon  three  packages  in  SM.  Accord¬ 
ing  to  the  description  of  the  CMVC. Initial  command  in  Rational  Environment  Reference  Manual 
11,  Project  Management,  if  the  parameter  Subsystem_Type  is  set  to  Cmvc. Combined  when  sub¬ 
systems  are  created,  then  circular  import  relations  may  hold  between  the  subsystems.  In  an 
initial  performance  of  the  experiment,  SM  and  CLI  were  created  as  combined  views,  SM  was  set 
to  import  CLI,  and  CLI  was  set  to  import  SM.  When  the  Cmvc.Make_Release  command  was 
issued  to  release  the  subsystems,  the  execution  of  the  command  never  finished.  The  subsystem 
AS  bre£/<s  the  import  circularity  and  consists  of  package  Aim_Support  and  package  specification 
and  body  for  String_Utilities,  which  were  originally  assigned  to  subsystem  CLI  by  the  experiment 
description. 
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2.1.  Introduction 


The  following  two  sections  describe  the  instantiation  of  the  two  configuration  management  experi¬ 
ments.  In  each  section  the  numbered  experiment  step  is  listed,  followed  by  an  overview  of  the 
Rational  commands  shown  in  braces  ({  }),  and  finally  a  detailed  list  of  the  Rational  commands. 
The  experiment  was  conducted  in  a  world  created  within  the  home  world  of  a  Rational  user.  The 
context  for  the  experiment  is  presented  as  WJser.experimenter.  If  repeating  the  experiment  is 
desired,  a  user  may  substitute  a  home  world  name  where  experimenter  appears  in  the  exper¬ 
iment  transcripts. 

The  transcript  indicates  specific  key  commands  by  showing  the  key’s  label  enclosed  in  angle 
brackets  (e.g.,  <Promot>).  The  first  time  a  command  is  used,  all  of  its  parameters  and  their 
values  are  detailed.  Parameter  values  that  must  be  supplied  or  that  vary  from  the  default  are 
written  in  italics.  Any  subsequent  uses  of  the  command  are  listed  with  only  required  parameters 
or  parameter  settings  that  vary  from  the  Rational  Environment  default  settings  written  in  italics. 

The  following  paragraphs  are  exeimples  of  how  to  change  current  context,  issue  commands,  and 
select  an  object.  They  are  provided  here  once,  so  that  the  detailed  list  of  Rational  commands 
need  not  be  an  exact  transcript  of  keystrokes. 

The  following  sequence  of  key  commands  may  be  used  to  change  to  an  example  context  direct¬ 
ory  lusers.experimenter.cm_experiment.cli: 

CPrcaapt.  For> 

<Deflnlt:lon>  —  A  command  windoK  opens 
—  con'taini.ngr : 

Common .  Definition  (Kama  »>  "<CXTRSOR>", 

In_Place  =>  False, 

Visible  =>  True) ; 

The  cursor  is  automatically  placed  at  the  parameter  value  for  Name,  enter  the  value  for  Name,  by 
typing: 

! users . experimenter . cm  experiment . cli 
<Promot> 

The  cursor  moves  to  the  window  least  recently  used,  and  a  listing  of  the  directory’s  contents 
!users.experimenter.cm_experiment.cli  appears  in  the  window. 

Another  method  of  changing  contexts  is  to  use  the  <Definition>,  <Enclosing>,  and  cursor  move¬ 
ment  or  arrow  keys.  For  example,  if  the  cursor  is  already  in  a  window  whose  context  is 
lusers.experimenterXo  make  lusers.experiment9r.cm_experiment.cliXhe  current  context: 

<dovm  arrow>  —  Press  until  the  cursor  is 

--  on  the  line  cm_experiinent ; 

<Definition>  --  the  cursor  will  move  to  a  window 

—  which  will  show  the 

—  -  iusers.  experimenter.  cm_experiment 

—  context . 

<down  arrow>  --  Press  until  the  cursor  is 

--  on  the  line  cli. 

<De£inition> 
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The  cursor  moves  to  a  window  listing  the  contents  of  the  directory 
!users.experimenter.cm_experiment.cli.  To  move  to  the  parent  of  the  current  context,  press  the 
key  <Enclosing>.  By  combining  the  use  of  the  <Enclosing>,  cursor  movement,  and  <Definition> 
keys,  any  context  can  be  reached  by  traversing  the  directory  tree  structure. 


Once  the  cursor  is  positioned  in  the  correct  context,  the  steps  to  issue  and  execute  a  command 
CommandJName  are  as  follows: 


<Crea'te  Coiiimand> 

Command_Name 


<Conjplt> 


—  A  command  window  opens . 

—  Type  in  the  command,  or 

—  a  unique  prefix  of  the 
- -  command . 

--  The  .command  will  be 
--  displayed  with  all 
--  parameters  and  their 
--  defaults. 


The  cursor  is  automatically  placed  at  the  value  for  the  first  parameter.  To  change  the  parameter, 
type  the  desired  value.  To  change  other  parameters,  move  the  cursor  to  the  parameter  value 
either  with  the  arrow  keys,  or  the  <Next  ltem>  key,  and  type  the  desired  value.  To  start  execution 
of  the  command,  press  the  <Promot>  key.  A  command  has  executed  without  error  if  no  error 
message  appears  in  the  system  message  window  at  the  top  of  the  Rational  screen,  or  if  in  the 
output  window  created  by  the  command,  no  asterisks  (*)  appear  in  the  left  column. 


To  select  an  object,  make  the  context  containing  the  object  the  current  context.  Place  the  cursor 
on  the  line  containing  the  object,  and  press  the  <Object>  key,  followed  by  the  <Left  Arrow>  key; 
The  object  is  then  displayed  in  brighter  characters  to  indicate  that  it  is  selected.  Some  com¬ 
mands  have  a  default  parameter  setting  of  <SELECTION>;  the  environment  resolves 
<SELECTlON>  to  be  an  object  that  is  selected  in  the  window  to  which  the  command  window  is 
attached.  It  is  often  faster  to  select  object,  and  allow  <SELECTION>  to  resolve  to  that  object. 


2.2.  Experiment  #1 

1 .  Experiment  setup 

a.  Create  subdirectory  in  which  the  experiment  will  be  performed. 

{The  subsystems  MAIN,  CLI,  SM,  VT,  and  AS  will  all  be  subdirectories  of 
Rational  World  "IUsers.expenrT7enfer.Cm_Experiment".} 

{Make  !  Users  .  expen'menfer  the  current 
context } 

<Create_World> 

Library .  Create_World  (Name  =>  ”  cm_expenment"  , 

Kind  =>  Library .World, 

Vol  =>  Library. Nil, 

Model  => 

’.'Model.  R 1 000_Ponable ", 

Response  =>  "<PROFILE>” ) ; 

b.  Establish  environment  variables  to  be  used  in  the  experiment. 

(None  are  used;  the  logical  names  assumed  by  the  experiment  will  be  used 
as  subsystem  names.} 
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c.  Develop  a  command  named  record  to  collect  data  file  size  measurement. 
{See  Appendix  A.} 

d.  Develop  a  command  named  timelt  to  collect  execution  time  measurements 
for  any  environment  command. 

(See  Appendix  A.} 

2.  Establish  Ada  program  library  structure  for  system  integration. 

(Use  the  Cmvc. Initial  command  to  build  an  initial  spec/load  working  view  for  the 
subsystems  VT,  AS,  SM,  CLI,  and  MAIN.} 

{Make  the  QDa_Experiinent  world  the  current  context .  } 

Cntvc .  Initial  (Subsystem  =>  "  VT" , 

Working_View_Base_Naine  =>  "Revl", 
Subsystem_Type  =>  Cmvc . Spec_Load, 
View_To_Import  *>  " " , 

Model  =>  "R1000_Portable", 

Comments  =>  " " , 

Work_Order  =>  "<DErAULT>", 

Volume  —>  0, 

Response  =>  "<PROFILE>") ; 

(Repeat  the  Cmvc.lnitial  command  as  above,  while  CM_Experiment  is  the  current 
context  for  each  of  the  other  subsystems:  SM,  CLI,  AS,  and  MAIN.  Allow  the  de¬ 
fault,  "Revl ,'  to  be  the  working  view  base  name  for  all  the  subsystems.} 

3.  Copy  existing  subsystems  into  integration  program  library  structure.  Assume  the 
existence  of  logical  names:  (AS),  VT,  CLI,  SM,  and  MAIN,  which  are  symbolic  links 
to  directories  containing  the  source  code  of  the  respective  subsystems.  Using 
these  logical  names,  copy  all  the  files  in  each  of  the  indicated  source  directories 
(AS,  VT,  CLI,  SM,  and  MAIN)  into  the  integration  program  library  structure.  Record 
initial  source  file  sizes. 

(Assume  that  \UseTS.experimenter.Cmvc_SouTce  with  subworlds  VT,  CLI,  SM, 
MAIN,  and  AS  exist.  Each  subworld  contains  its  Ada  source  units.  Use  the  Library 
Copy  command  and  its  recursive  copy  parameter  to  move  the  Ada  source  units  into 
the  subsystem  structure  set  up  above.} 

{Mjike  tUsars  .  experfmen/er.  Cmvc_Source  the  current 
context . } 

Library . Copy 
(From  => 

”  !Users.experimenter.Crnvc_Source.As” , 

To  => 

"  iUsers.experimenter.  Cm_Experiment. 

As.Rev1_  Working.  Units " , 

Recursive  =>  True, 

Copy_Links  s>  False, 

Response  s>  <PROFXLE>; 

(Put  the  Ada  units  placed  in  the  initial  spec/load  working  view  under  access  control 
by  using  the  Cmvc.Make_Controlled  command  and  the  wildcard  to  indicate  all  units 
in  the  directory.} 
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{Make  !  Users .  experimenter.  Cm^Experiment . 

As  .Revl_Wor3cing.  Units  the  current  context.} 

Cnrvc  .Make_Cont rolled  (What_Object  =>  ”  , 

Reservation_Token_Neune  => 
"<AUTO_GENERATE>" , 

Join_With_View  =>  "<None>", 

CoBoments  => 

Work_Order  =>  "<DEFAULT>", 

Response  =>  "<PROFILE>") ; 

{Repeat  the  above  procedures  (Library. Copy  and  Cmvc.Make_Controlled)  for  each 
of  the  subsystems  (CLI,  MAIN,  SM,  and  VT),  placing  the  subsystem's  Ada  units  into 
the  appropriate  Rev1_Working. Units  subdirectory,  and  placing  the  Ada  units  under 
access  control.} 

4.  Define  a  new  (integrated)  system  model  from  existing  subsystems.  This  system 
model  specifies  the  compilation  dependendes  in  effect  when  integrating  all  of  the 
individual  subsystems. 

(Create  for  each  subsystem  a  spec  view  composed  of  the  default — a  copy  of  all  the 
package  specifications  vflthin  the  subsystem.) 

(Make  !  Us«rs  .  experimenter.  Cin_Expttriiaent .  As 
the  current  context,  and  place  the  cursor  on 
Revl_Working . } 

Cnrvc. Make_Spec_View(Froia_Path  =>  "<CURSOR>", 

Spec_View_Pre£ix  =>  "As", 

Iievel  =>  0 , 

View_To_Modi£y  =>  " " , 

View_To_Injport  => 

"<INHERIT_IMPORTS>" , 
Only_Change_Iinport s  =>  True, 
Reinake_pemoted_Units  =>  True, 

Goal  s>  Compilation . Coded, 

Comments  =>  " " , 

Work_Order  =>  "<DEFAULT>", 

Volume  =>  0, 

Response  =>  "<PROFILE>") ; 

(Repeat  the  creation  of  spec  views  for  subsystems  SM,  CLI,  and  VT,  giving  the 
Spec_View_Prefix  as  "Sm,"  "Cli,"  and  "Vt,"  respectively.) 

(Due  to  a  bug  in  the  Make_Spec_View  command,  the  spedfication  units  copied  to 
the  spec  view  are  not  automatically  promoted  to  the  state  indicated  by  the  Goal 
parameter.  It  is  necessary  to  visit  all  spec  views  and  promote  any  units  they  con¬ 
tain  to  coded  state.  Because  of  dependencies  between  the  spec  views,  the  order  in 
which  the  spec  views  are  promoted  is  important.) 

(Make  !  Usars  .  experimenter.  Cm_Experiment .  Vt . 
the  current  context,  and  place  cursor  on 
Vt_0_Spec .  } 

<Code  (This  World) > 

(Promote  the  Ada  units  in  !Users.experimenfef.Cm_Experiment.As.As_0_Spec  to 
coded  state  also.  Before  the  Ada  units  in  !Users.expen'menfer.Sm.Sm_0_Spec  and 
!Users.expenmenfef.Cli.Cli_0_Spec  can  be  promoted,  imports  for  these  spec  views 
must  be  created.  The  spec  view  of  SM  depends  upon  definitions  in  the  spec  view 
of  AS  and  VT.  The  spec  view  of  CLI  depends  upon  definitions  in  the  spec  view  of 
AS. 
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{Make  ! Users  .  experimenter.  Cla_Experiment .  Sm.  Sm_0_Spec 
the  current  context . } 

Cmvc .  Import  (view_To_iiiiport  =>  lUsers.experimenter. 

Cm_Experiment. 

[As.As_0_Spec,  Vt.  Vt_0_Spec], 

Into_View  =>  "<CURSOR>", 

Only_Change_Imports  =>  False, 

Iinport_Closure  =>  False, 

Reinake_Deinoted_Units  =>  True, 

Goal  s>  Con^ilation. Coded, 

Comments  => 

Work_Order  =>  "<DEFAULT>", 

Response  =>  "<PROFILE>") ; 

(Place  cursor  on 

! Users  .  experimenter.  Cm_Experimant .  Sm.  Sm_0_Spec .  } 

<Code  (This  World) > 

(Make  ! Users  .  experimenter.  Cm_Experiinent .  Cli .  Cli_0_Spec 
the  current  context . } 

Cmvc .  Import  (view_To_import  =>  lUsers.experimenter. 

Cm_Experiment.As.As_0_Spec)  ; 

(Check  that  cursor  is  on 

!  Users  .  experimenter.  Cm_Experiment .  Cli .  Cli_0_Spec . } 

<Code  (This  World) > 

{Create  the  import  list  for  each  subsystem's  working  load  view;  MAIN  imports  the 
spec  views  of  VT,  CLI,  and  SM.  The  order  in  which  these  imports  are  performed  is 
unimportant:  they  must  only  occur  before  attempts  to  compile  units  in  the  working 
load  views  of  the  subsystems.} 

(Make  ! Users  .  experimenter.  Cm_Experiment  .Main . 

Revl  Working. Units  the  current  context.) 

Cmvc . Import (View_To_Import  «> 

lUsers.experimenter.  Cm_Experiment. 

[Vt.Vt_0_Spec,  Cli.Cli_0_Spec, 

Sm.Sm_0_Spec]) ; 

(CLI  imports  the  spec  views  of  AS,  VT,  and  SM:} 

(Make  ?  User s  .  experimenter.  Cm_Experiment .  Cli . 

Revl_Working. Units  the  current  context.) 

Cmvc .  Iiiq»ort  (View_To_Import  => 

lUsers.  experimenter.  Cm_  Experiment. 

[As.As_0_Spec,  Vt.  Vt_0_Spec, 

Sm.Sm_0_Spec])  ; 

(SM  imports  the  spec  view  of  VT  and  AS:} 

(Madce  !  Users  .  experimenter.  Sm_Experiment .  Sm . 

Revl  Working. Units  the  current  context.) 

Cmvc . Import (View_To_Import  => 

.'Users,  experimenter.  Cm_  Experiment. 

[As.As_0_Spec,  Vt.  Vt_0_Spec])  ; 

(Create  the  Activity  Table,  which  is  a  listing  of  subsystems  with  their  corresponding 
spec  views  and  load  views.} 
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{ Make  !  Users  .  experimenter .  Cm_Experiment 
the  current  context . } 

Activity . Create (The_Act ivity  =>  "AIM_B0 1 "  , 

Source  =>  Activity . Nil, 

Mode  =>  Activity .Exact_Copy, 

Response  =>  "<PROriLE>" ) ; 

{Make  AIM_B01  the  current  context;  insert  entries.  The  order  in  which  entries  are 
added  is  not  important  as  the  editor  maintains  them  in  alphabetical  order  by  subsys¬ 
tem  name.} 

<Object>  I 


Insert  (Sxibsystem 

=> 

"  Main" , 

Spec^yiew 

=> 

(f  t( 

f 

Load  View 

=> 

"  Rev  1_  Working" ) ; 

<Object>  I 

Insert  (Subsystem 

=> 

"  Sm" , 

Spec__View 

=> 

"  Sm_0_Spec" , 

Load  View 

*> 

"  Rev1_  Working" ) ; 

<Object>  I 

Insert  (Sxibsystem 

=> 

"  Cli" , 

Spec^View 

=> 

”  Cli_0_Spec" , 

Load  View 

=> 

"  Rev  1_  Working" ) ; 

<Object>  I 

Insert  (Sxibsystem 

=> 

”Vr\ 

Spec_yiew 

=> 

"  Vt_0_Spec" , 

I#oad__View 

=> 

" Rev1_Working") ; 

<Object>  I 

Insert  (Sxibsystem 

=> 

"As" , 

Spec_yiew 

=> 

"As_0_Spec” , 

Load_yiew 

=> 

" Rev1_Working") ; 

{The  entries  must  be  saved  by  typing: } 

<Enter> 

{Make  AXM_B01  the  default  activity  with  the  following 
commands : } 

Set_Default (The_Act ivity  =>  "AIM_B01", 

Response  =>  "<PROriLE>" ) ; 

5.  Build  an  executable  load  module  named  AIM_B01_EXE  from  all  the  Ada  source 
code  files;  use  the  system  model  defined  in  Step  4  where  appropriate.  Measure 
time  taken  to  perform  the  build. 

(Promote  all  the  Ada  units  in  the  load  views  to  coded  state,  using  the 
Compilation. Promote  command,  which  relies  on  the  subsystem  structure  and  im¬ 
ports  to  determine  compilation  order.) 
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{Make  !  Users  .  BxperimBnter.  Cin_Experlment 
the  current  context . ) 

Con^llatlon. Promote  (Unit  =>  " $.[M3in,As,Vt,Sm,CH]. 

Rev1_Working” , 

Scope  => 

Compilation . Subunit s_Too , 

Goal  s>  Con^llat Ion.  Codsd, 

Limit  =>  "<ALL_WORLDS>" , 

Effort_Only  =>  False, 

Response  =>  "<PROFILE>") ; 

{Select  and  promote  Main  in  subsystem  MAIN,  to  cause  a  link  of  the  closure  and 
the  creation  and  execution  of  a  load  module.} 

{Make  !  Users  .  experimenter.  Cm_Experlment . Main . 

Revl  Working. Units  the  current  context;  select 
Main' body. } 

<Promot> 

{Observe  the  creation  of  an  output  window,  and 
" It  works ! "  appears  In  the  window . ) 

6.  Construct  a  configuration  baseline  named  B0.1  of  the  current  system.  Measure 
time  taken  to  create  the  CM  files.  Record  initial  sizes  of  CM  files.  Measure  time 
taken  to  perform  baseline  operation. 

{Release  all  of  the  subsystems  and  aeate  an  Activity  which  specifies  the  spec 
views  and  released  load  views.  Note  that  because  the  Cmvc.Release  command  is 
actually  making  a  copy  of  each  subsystem,  it  takes  some  time  to  complete.} 
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( Make  !  Us  a  r  s .  experimenter .  Cm_^£xpe  rime  nt 
the  current  context } 

Cxnvc .  Release  (rrooi_Working_View  => 

"  !Users,experimenterCm_Experiment 
[Main,  Sm,  Cli,  Vt,  As],Rev1_Working^^ 

Release_Name  =>  ”<AUTO_GENERATE>” , 

Level  =>  0  f 

Views_To_Ixnport  =>  '*<INHERIT_IMPORTS>" , 
Create_Configuration_Only  =>  False, 
Con^ile^The^JView  =>  True, 

Goal  =>  Compilation . Coded, 

Comments  => 

Work_Order  =>  "<DErAULT>" , 

Volume  =>  0, 

Response  =>  '*<PROriLE>")  ; 


Activity .  Create  (The_Activity  =>  "  S0_  7"  , 
Source  =>  "Aim^BOl"*)  ; 
NOTE:  The  value  for  the  parameter  Source  must 
be  in  quotes. 


(Make  !  Users  .  experimenter.  Cm_^Expe r iment .  BO^l 
the  current  context  and  insert  entries  with 
the  following  commands : } 

<Object>  I 

Insert  (Subsystem  =>  ”Ma/77”, 

Spec_View  => 

Load_View  =>  ”  Rev1_0_  7  " )  ; 

<Object>  I 

Insert  (Subsystem  =>  "Sm”, 

Spec_View  => 

Load_View  =>  Rev1_0_V')  ; 

<Object>  I 

Insert  (Subsystem  =>  ”  C//”  , 

Spec_J7iew  =>  '*  ”  , 

Load_yiew  =>  •’/?ev^7_CL7'’)  ; 

<Object>  I 

Insert  (Subsystem  =>  ”  Vt' , 

Spec_View  => 

Load_View  =>  ”/?ev^7_0_7")  ; 

<Object>  I 

Insert  (Subsystem  =>  "^S", 

Spec_View  =>  , 

Load_View  =>  ”f?e\^7_0_7")  ; 

{Save  the  new  entries  in  the  activity  by  typing:} 

<Enter> 


7.  Parallel  test  the  integrated  system  using  three  variants  of  main  program  (MAIN.A, 
MAIN.B,  MAIN.C).  Measure  time  for  single  file  fetch,  reserve,  and  replace 
operations. 

MAIN .A  -  test  VT  interfaces 


MAIN.B  -  test  CLI  interfaces 
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MAIN.C  -  test  SM  interfaces 

{Create  3  parallel  development  paths  from  the  released  subsystem  MAIN--vttester, 
dltester  and  smtester.  Note  that  these  names  would  be  much  more  readable  as 
"vt_tester,"  "dijester,"  and  "sm_tester';  however,  due  to  a  limitation  of  the 
Cmvc. Build  command  used  later,  no  underscores  (J  can  be  used  In  a  user- 
designated  pathname.} 

{Make  !  Users .  experimenter.  Cm_Experiment . Main 
the  ciirrent  context} 

Cntvc.Make_Path  {rro*n_Path  => 

"  lUsers.experimenter. 

CmJExperiment.  Main.  Rev  1_0_1” , 

Kew_Path_Kaine  =>  "  Vttester , 

View_To_Modify  => 

View_To_Iinport  «>  "<IKHI:RIT_IMP0RTS>"  , 
Only_Change_Iinports  »>  True, 

Model  =>  "<IKHERIT_MODEL>", 

Join_Paths  =>  False, 

Rexnake_pemoted_Units  True, 

Goal  s>  Coopilation. Coded, 

Coosnents  *> 

Work_Order  »>  "<DErAULT>", 

Volume  =>  0 , 

Response  =>  "<PROriLE>") ; 

Cmvc . Make_Path  {Froai_Pat h  s> 

"  lUsers.experimenter. 

Cm_Experiment.Main.Rev1_0_1'' , 

Kew_Path_Kaine  =>  "Clitester", 

Join_Paths  =>  False)  ; 

Cnnrc .  Make__P  at  h  ( rrom_P  at  h  => 

"  lUsers.  experimenter. 

Cm_Experiment.Main.Rev1_0_1” , 

Kew_Path_Kame  =>  "Smtester", 

Join_Paths  =>  False)  ; 

a.  Test  VT  interfaces. 

i.  Build  executable  load  module  named  VT_MAIN  using  MAIN.A  as 
the  main  program.  Measure  time  taken  to  perform  the  build. 
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{Make  !  Users  .  experimenter.  Cm^Experiment . 

Main.  Vtte St er^Working.  Units  .Main'  body  the 
current  cont  ext } 

<Check  Out> 

<Install  Unit> 

{Place  cursor  in  body,  after  the 
Text_IO .  Put_Line  statement .  } 

<Object>  I 

{An  edit  window  opens  and  the 
cursor  is  placed  in  it  automatically; 
insert  the  code  line : 

Text_IO .  Put_line 

(”This  is  the  VT  Driver.  ”)  ;  } 

<Format> 

{Place  the  new  code  line  back 
into  the  program. } 

<Promot> 

{Return  the  entire  unit  to 
coded  state . } 

<Promot> 

<Check  In> 

li.  Fix  bugs  in  VT  body  (using  variant  line  of  descent).  Measure  time 
taken  for  creating  a  variant  line  of  descent.  Measure  CM  file  size 
increase  caused  by  variant 

{Since  other  programmers  working  on  the  system  will  be  linked  with 
the  release  version  of  subsystem  VT,  the  programmer  responsible 
for  updates  to  Page_Terminarbody  can  continue  to  work  in  the 
Rev1__Working  version  of  the  subsystem.} 

{Make  !  Users  .  experimenter.  Cm_Elxperiinent .  Vt . 
Revl_Working .  Units  .  Page_Terminal '  body  the 
current  context . } 

<Check  Out> 

<Edit> 

{Replace  the  null  statement  with; 

Text^IO .  Put^Line 

("Elaborating  Page_Terminal  Body. ") ; } 

<rormat> 

<Code  Unit> 

<Check  In> 

iii.  Construct  a  configuration  baseline  named  B0.2  of  the  current  sys¬ 
tem  using  MAIN.A  as  the  main  program.  Record  current  sizes  of 
CM  files.  Measure  time  taken  to  perform  baseline  operation. 

(Create  a  release  of  the  VT  subsystem;  create  an  Activity  B0_2 
which  uses  the  new  release  of  the  VT  subsystem  and  Path  VTtester 
for  Main.) 
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{Make  !  Users  .  experimenter.  Cm^Hlxperiment . 

Vt . Rev l_Hor king • Units  the  current  context . 

NOTE:  Use  all  defaults  In  Cmvc.  Release  command. } 

Cmvc. Release 

(Make  !  Users  .  experimenter.  Qoi__Experiinent 
the  current  context . } 

Activity .  Create  (The__Activity  =>  "  , 

Source  =>  ”S0_7")  ; 

(Make  !  Users  .  experimenter.  Qctt^Experixnent . 

B0_2  the  current  context .  } 

<Object>  I 

Insert  (Subsystem  =>  "Mcdn'\ 

Spec__VieK  =>  "  ” , 

Load^view  =>  Vttester^Working**) ; 

<Object>  I 

Insert  (Subsystem  =>  "  VV^ , 

Spec_View  => 

Load_View  =>  ; 

<Enter> 

{Make  Activity  B0_2  the  default  activity  and  execute  the  system.) 

Set_pefa\ilt  (The_jActivity  =>  ”S0_2”)  ; 

{ Make  !  Us er s  .  experimenter .  Qm^Expe riment . 

Main. Vtteste reworking. Units  the 
current  context  and  select  Main' body.} 

<Promot> 

(Observe  the  creation  of  an  output  window; 

” Elaborating  Page^Terminal  Body . " , 

"It  works!"  and  "This  is  the  VT  Driver." 
appear  in  the  window . } 

b.  Test  CLI  interfaces 

i.  Build  executable  load  module  named  CLi_MAIN  using  MAIN.B  as 
the  main  program.  Measure  time  taken  for  creating  a  variant  line  of 
descent.  Measure  CM  file  size  increase  caused  by  variant.  Measure 
time  taken  to  perform  the  build. 

(Make  Activity  B0_1  the  default  activity,  edit  Main  in  Clitester 
subpath.} 
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Activity .  Set_^Default  (The_Activity  => 

"  lUsers.expehmenter.  Cm_Expehment 
BO_V^ 

{ Make  !  Us e r s  .  experimenter .  Cm_Expe r iment . 

Main .Clitester_Working. Units .Main' body 
the  cxirrent  context .  } 

<Check  Out> 

<Install  Unit> 

{Place  cursor  in  body  after 
the  Text_IO .  Put_Line  statement .  } 

<Object>  I 

{An  edit  window  opens  and  the  cursor 
is  placed  in  it  automatically. 

Insert  the  code  line : } 

Text_IO.Putline 

(”This  is  the  CLI  Driver.”);} 

<Promot> 

Fix  bugs  in  MAIN.B.  {Note  that  Putline  is  underlined  as  an  error.} 

(Correct  Putline  to  be  Put_Line;  place  the 
new  code  line  back  into  the  program. } 

<Promot> 

(Return  the  entire  unit  to  coded  state.} 
<Proniot> 

<Check  In> 

Construct  a  configuration  baseline  named  B0.3  of  the  current  sys¬ 
tem  using  MAIN.B  as  the  main  program.  Record  current  size  of  CM 
files.  Measure  time  taken  to  perform  baseline  operation. 

(Create  Activity  B0_3:  make  it  the  current  activity;  and  link,  load,  and 
execute  system.} 


{Make  \  Users  .  experimenter.  Cni_Expe r iment 
the  current  context . } 

Activity  •  Create  (The^Activity  =>  "  50_3" , 

Source  =>  "B0_  1**)  ; 

NOTE:  The  value  for  the  parameter 
Source  must  be  in  quotes. 

{Make  !  Users  .  experimenter.  Cm^^Experiment . 

B0_3  the  ciirrent  context .  } 

<Object>  I 

Insert  (Subsystem  s>  *^Main*^f 
Spec_VieH  => 

Load_view  =>  "  C//fesfer_  IVorfc/ng" )  ; 

{Save  the  new  entries.} 

<Enter> 

Set_Default  (The_Activity  =>  "S0_3”)  ; 

{Make  I  Users  .  experimenter.  Cm_Experiment 
.Main. elites te reworking. Units  and  select 
Main' body. } 

<Promot> 

{Observe  the  creation  of  an  output  window. 

”It  works!"  and  "This  is  the  CLI  Driver." 
appear  in  the  window. } 

c.  Test  SM  interfaces. 

i.  Build  executabie  ioad  moduie  named  SM_MAIN  using  MAiN.C  as 
the  main  program.  Measure  time  taken  to  perform  the  build.  Meas¬ 
ure  time  taken  for  creating  a  variant  line  of  descent.  Measure  CM 
file  size  increase  caused  by  variant. 

{Make  Activity  B0_1  the  defauit  activity,  edit  Main  in  Smtester  sub¬ 
path,  iink,  load  and  execute.} 
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Activity . Set^Default {The_Activity  => 

” !  Users,  experimenter.  Cm_Experiment. 

BO_V' 

{ Make  !  Us e r s  .  experimenter .  Cm_^Expe  rixoent . 

Main. Smte St er_J?or king. Units  .Main' body 
the  current  context . } 

<Install  Unit> 

{Place  cursor  in  body  after 
the  Text  lO.Put  Line  statement. } 

<Object>  I 

{An  edit  window  opens  and  the 
cursor  is  placed  in  it  automatically; 
insert  the  code  line: 

Text^IO .  Put^Line 

{"This  is  the  SM  Driver.");} 

{Place  the  new  code  line  back  into 
the  program. } 

<Pro«not> 

{Return  the  entire  unit  to  coded 
state. ) 

<Promot> 

<Check  In> 

{Make  !  Users  .  experimenter.  Cm_^Experiment . 

Main. Smtester^Korking. Units  the  current 
context  and  select  Main' body.) 

<Promot> 

{Observe  the  creation  of  an  output  window. 

"It  works!"  and  "This  is  the  SM  Driver." 
appear  in  the  window. } 

ii.  Add  new  interface  to  Viewport_Manager  package  (using  variant 
versions).  Measure  time  taken  for  creating  a  variant  line  of  descent. 
Measure  CM  file  size  increase  caused  by  variant. 

{Add  function  definition  to  Viewport_Manager  specification,  add 
function  to  Viewpor1_Manager*body,  make  a  new  spec  view  of  sub¬ 
system  SM.  update  subsystems  which  import  subsystem  SM.} 
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{Make  !  Users .  experimenter,  Cm^Experiment .  Sm. 
Revl^Working . Units  .  Viewport^^nager '  spec 
the  current  context • } 

<Check  Out> 

{Place  cursor  after  sxibtype  V^String 
definition. } 

<Object>  I 

{An  edit  window  opens;  type  in  the 
specification: 

"function  I^Do_Nothing  return  Boolean;"} 
<7ormat> 

<Promot> 

<Check  In> 

{Make  !  Users  .  experimenter,  Cm^Experiment .  Sm. 
Revl_Working ,  Units  .  Viewport_Manager '  body 
the  current  context . } 

<Check  Out> 

<Edit> 

{After  "package  body  is"  line,  add: 

fxinction  I^Do_Nothing  return  Boolean  is 
begin 

return  True; 
end  I  Do  Nothing;  } 

{Replace  null  statement  in  package  body 
with; 

Text^Io . Put^Line ( " Elaborating 

Viewport_Manager  Body - " ) ;  } 

<Code  Unit> 

<Check  In> 

{ Make  !  Users  .  experimenter.  Cm__Experiment .  Sm . 
Revl_Working  the  current  context . } 

Cnrvc .  Make__Spe  c_Vie  w  ( Spe  c_y  ie  w^P  re  f  ix  => 

"SM", 

Level  =>  7)  ; 

{Due  to  bug  in  Cmvc.Make_Spec_View 
command,  \inits  in  the  new  spec  view 
must  be  manually  promoted  to  coded  state; 
make  !  Users  .  experimenter.  Cm^Experiment . 
Sm.Sm^l^Spec  the  ctirrent  context.) 

<Code  (This  World) > 

{Make  !  Users  .  experimenter.  Cm^Experiment . 

Main . Smtester^Working  the  current 
context . } 

cave .  Import  (view^To_import  =>  " ! Users. 

experimenter.  Cm_Experiment.  Sm.  Sm_  1_Spec)  ; 

{Make  !  Users  .  experimenter .  Cm^Experiment . 

Cli . Revl^Working  the  current  context.) 
cave .  Import  (View^To^Import  =>  " ! Users. 
experimenter.Cm_Experiment.Sm.Sm_  1_Spec)  ; 

iii.  Rebuild  executable  load  module  named  SM  MAIN  with  new  version 
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of  the  Viewpoi1_Manager.  Test  new  interface  along  with  previous 
interfaces  of  the  SM.  Measure  time  taken  to  perform  the  build. 

(Construct  an  activity  Aim_B04  which  will  test  the  new  spec  view 
and  driver  for  Sm.} 

{ Make  I  Us  er s .  experimenter,  csn^Expe  riment. 
t.he  current,  context . } 

Activity .  Create  (The__Activity  =>  **Aim_B04'\ 
Source  =>  ; 

NOTE:  The  value  for  the  parameter 
Source  must  be  in  quotes. 

{Make  !  Users  .  experimenter.  Cm^Expe riment , 

Aim_B04  the  current  context} 

<Object>  I 

Insert  (Stibsystem  =>  "Ma/n”, 

Spec_View  =>  , 

Load_view  =>  Smtester^Working*') ; 

<Object>  I 

Insert  (Subsystem  =>  "S/77", 

Spec__View  *>  "  Sm_  /_Spec" , 

Load^Viaw  »>  "flevf_l/Vorfc/ngr" )  ; 

{Save  the  new  entries.} 

<Enter> 

Set_De fault  (The^Activity  =>  "yA//77_S04" )  ; 

{Make  !  Users  .  experimenter.  Cm__Experiment . 

Main .  Szntester^Working .  Units  the  current 
context,  and  select  Main' body.} 

<PrO(mot> 

{Observe  the  creation  of  an  output  window; 

" Elaborating  Viewport__Manager  body.", 

"It  works!"  and  "This  is  the  SM  Driver." 
appear  in  the  window . } 

iv.  Construct  a  configuration  baseline  named  B0.4  of  the  current  sys¬ 
tem  using  MAIN.C  as  the  main  program  and  the  new  versions  of  the 
Viewport  Manager.  Record  current  sizes  of  the  CM  files.  Measure 
time  taken  to  perform  baseline  operation. 

{Create  a  release  of  the  SM  subsystem;  create  an  Activity  B0_4 
which  uses  the  new  release  of  the  SM  subsystem  and  Path 
Smtester  for  Main.} 
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{Make  !  Users  .  experimenter.  CXn^Experlment . 

Sm . Revl^Working . Units  the  current  context . 

NOTE:  Use  all  defaults  in  Cmvc.Release  command.) 

Cxovc .  Release 

(Make  !  Users  .  experimenter.  CXn^Experixnent 
the  current  context . } 

Activity .  Create  (The_Act ivity  =>  *'  , 

Source  =>  "Aim_B04'*)  ; 

NOTE:  The  value  for  the  parameter  Source  must 
be  in  quotes. 

(Make  !  Users  .  experimenter.  Cm_Experixnent . 

B0_4  the  current  context} 

<Object>  I 

Insert  (Subsystem  =>  ”S/77", 

Spec_VieH  =>  ”  Sm_  1_Spec” , 

Load_VieH  =>  ”  Rev  1_  7_  7  " )  ; 

{Save  the  nen  entry.} 

<Enter> 

{Make  Activity  B0_4  the  default  activity  and  execute  the  system.) 

Set_^Def  ault  (The_Activity  =>  ; 

{Make  !  Users  .  experimenter.  Cm^Experiment . 

Main .  Sxntester^Working .  Units  the 
cxirrent  context  and  select  Main' body.} 

<Proinot> 

{Observe  the  creation  o£  an  output  window; 
"Elaborating  Viewport^Manager  Body." 

"It  works!"  and  "This  is  the  SM  Driver." 
appear  in  the  window . } 

8.  Merge  bug  fixes  and  enhancements  back  into  main  line  of  descent  for: 

a.  Main  program 

b.  VT  package  body 

c.  VM  package  specification  and  body 

Measure  time  to  perform  merge  operations.  Record  CM  file  size  increases  caused 
by  merge  operations. 

{Use  the  Cmvc.Merge_Changes  command  to  merge  Main’body  from 
Vttester_Working.  Clitester_Working.  and  Smtester_Working  back  into 
Rev1_Working.} 
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{ Make  !  Users  .  experimenter,  Cm^Experiment . 

Main.Revl  Working. Units  the  current  context^ 
select  Main' body.} 

Cmvc .Me r gearchanges  (Destination^Ob  ject  => 

”<SELECTION>", 

Source_View  =>  ”  lUsers. 
experimenter.  Cm^Experiment. 

Main.  Vttester_Working, 

Report_rile  => 

Fail_If_Conflicts_Found  =>  False, 
Comments  => 

Work_Order  =>  "<DEFAULT>", 

Response  =>  "<PROFILE>") ; 

{Check  Main  Merging  Report  to  see  if  merge  occurred 
successfully. } 

{Select  Main' body} 

cave  .Merge_Changes  (Destination  =>  "<SELECTION>’' , 

Source_view  =>  "  I  Users, 
expenmenter.  Cm_Experiment. 

Main.Clitester_Working)  ; 

{Check  report  to  see  where  conflicts  occurred; 
select  Main' body} 

<Edit> 

{Remove  ”*;1”  and  ”*;2"  from  the  beginning  of 
"conflicting”  lines.} 

<Next  Itexn> 

<Control>  D 
<Control>  D 
<Control>  D 
<Forxnat> 

<Control>  D 
<Control>  D 
<Control>  D 
<Code  Unit> 

<Check  In> 

{ Select  Main ' body . } 

Cxovc  .Me rge_Changes  (Destination  =>  "<SELECTION>"  , 
Source_View  *>  "/Users. 
experimenter.  Cm_Experiment.Smtester_  Working)  ; 

{Check  report  to  see  where  conflicts  occurred; 
select  Main' body.} 

<Edit> 

{Remove  "*1;"  and  "*2; "  from  the  beginning  of 
"conflicting"  lines.} 

<Code  Unit> 

<Check  In> 

{To  "merge"  the  bug  fixes  and  enhancements,  the  experimenter  need  only  pick  up 
the  latest  release  of  subsystems  VT  and  SM  in  the  subsequent  experiment  step.} 

9.  Add  prologues  to  package  specifications  and  bodies.  Measure  time  for  single  file 
reserve  and  replace  operations. 
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{Make  !  Users  .  expehmentQr.  Cm^Experiznent: . 

Vt: . Re vl^Wor king. Units  current  context  and 
place  cursor  on  Vt^^Support '  spec .  } 

<Mark>  <Begin  0f> 

<De  f init ion> 

<Check  Out> 

{Place  cursor  at  beginning  of  file.} 
<Iinage>  <Begin  0f> 

<Object>  I 

{An  Edit  window  opens enter  the  prologue:} 


—  This  is  a  sample  Ada  program  prologue : 

—  Author : 

Unit  Name : 

--  Creation  Date : 

Update  History: 


<Promot> 

<Check  In> 

<Mar3c>  <End  Of> 

{To  repeat  the  above  prologue  insertion 
procedure  for  each  of  the  package 
specifications  and  bodies  in  the 
Revl_Working  views  of  all  the  subsystems, 
the  <Mark>  <Begin  Of>  and 
<Mark>  <End  Of>  commands  above 
have  created  a  macro,  which  now  may 
be  bound  to  a  key . } 

Editor . Macro . Bind (Key  =>  ”  FI " ) ; 

{Now  place  the  cursor  on  any 
package  specification  or  body  while 
in  its  enclosing  context,  and  the 
commands  to  insert  the 
prologue  template  above  will  be 
repeated  with  the  press  of  key 
<ri>. } 

10.  Construct  a  configuration  baseline  named  V1.0  of  the  current  system.  Record  cur- 
rent  sizes  of  CM  files.  Measure  time  taken  to  perform  baseline  operation. 

{Release  all  the  subsystems,  create  Activity  V1_0,  and  make  Activity  V1_0  the  de¬ 
fault  activity.} 
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{Make  !  Users  .  experimenter ,  Cni^Expe r ime nt  the  current 
context . } 

Cxnvc .  Release  (From_Wor}cing_View  => 

lUsers.  experimenter. 

Cm_Experiment[Vl  Sm,  Cli^As,  Main]. 

Rev1_Working)  ; 


Activity .  Create  (The_Activity  =>  ”  , 

Source  =>  "60_O  ; 

NOTE:  The  value  for  the  parameter  Source  must 
be  in  quotes. 


(Make  !  Users  .  experimenter.  Cm_Experiment .  V1_0 
the  current  context  and  insert  entries  with 
the  following  commands : } 

<Object>  I 

Insert  (Subsystem  =>  "Ma/n", 

Spec_View  => 

Load_View  =>  ”  f?ev^7_CL2" )  ; 


<Objact>  I 
Insert (Subsystem  => 
Spec^View  => 
Load  View  => 


"  Sm” , 

"  Sm_  7_Spec" , 
'*/?ev^7_7_2")  ; 


<Object>  I 
Insert (Subsystem  s> 
Spec_yiew  => 
Load  View  => 


”  C//" , 

II II 

f 

"Rev1_0_2”)  ; 


<Object>  I 
Insert.  (Subsystem  => 
Spec_View  => 
Load  View  => 


"  Vt” , 

II  II 

t 

"Rev1_0_3")  ; 


<Object>  I 
Insert (Subsystem  => 
Spec_View  => 
Load  View  s> 


"As” , 

II  It 

r 

"Rev1j0_2")  ; 


{Save  the  entries:} 
<Enter> 


Set_Default  (The_Activity  =>  "l^7_0"); 

1 1 .  Build  executable  load  module  name  Product  using  all  current  source  code. 


{In  order  to  create  a  code  view  of  the  subsystems  which  can  be  executed,  a  spec 
view  for  subsystem  Main  must  be  created.} 


{ Make  !  Us e r s  .  experimenter .  Cm_Ebcpe r iment . 
Main . Rev 1_0_2  the  current  context.} 

Cntvc .  Make_Spec_View  (Spec__View^Pref  ix  => 

“Main% 

Level  =>  7)  ; 

{ Due  to  a  bug  in  the  Cmvc .  Make_Spec__View 
command^  tinits  in  the  new  spec  view 
must  be  manually  promoted  to  coded  state, 
make  !  Users  .  experimenter.  Cm_Experiment . 

Main . Mai n_0_Spec  the  current  context.} 
<Code  (This  World) > 


CMU/SEI-88-TR-21 


25 


{Create  a  code  view  of  each  of  the  subsystems  and  an  Activity  which  references 
them.) 

{Make  !  Users  .  experimenter.  Cm_Experiment . 
the  current  context . } 

Curve .  Make_Code_View  ( 

From_View  =>  ”  $.[Main.Rev1_0_2, 

Sm.Rev1_1_2, 

Cli.Rev1_0_2. 

Vt.Rev1_0_3, 

As.Rev1_0_2]” , 

Code_view_Naine  =>  "Product”, 

Comments  =>  " ” , 

Work^Order  =>  "<DEFAULT>", 

Voliima  =>  0, 

Response  =>  '’<PROFILE>")  ; 

{Create  an  Activity  named  Product, 

Make  !  Users  .  experimenter.  Cm_Experixnent 
the  current  context . } 

Activity .  Create  (The^^Activity  «>  ”  PrvducV' , 

Soiirce  — >  ; 

NOTE:  The  value  for  the  parameter  Source  must 
be  in  quotes. 

{ Make  !  Us  e r s  .  experimenter.  Cm^Expe riment . 

Product  the  current  context . } 

<Object>  I 


Insert  (Siibsystem 

=> 

"  Main” , 

Spec_View 

=> 

”  Main_0_Spec” , 

Load  View 

»> 

"  Product” ) ; 

<Object>  I 

Insert  (Siibsystem 

=> 

"  Sm” , 

Spec__View 

=> 

t 

Load  View 

=> 

"Product”) ; 

<Object>  I 

Insert (Subsystem 

=> 

"  Cli” , 

Spec_yiew 

=> 

(f  M 

r 

Load  View 

=> 

"Product”) ; 

<Object>  I 

Insert (Subsystem 

=> 

"  Vt\ 

Spec^View 

=> 

If  II 

f 

Load  View 

=> 

"  Product" ) ; 

<Object>  I 

Insert (Subsystem 

=> 

"As” , 

Spec_View 

=> 

It  II 

r 

Load_View 

=> 

”  Product” ) ; 

{Save  the  entries:} 

<Enter> 

Set_Default  (The_Activity  =>  Product'); 
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{Make  !  Users  .  experimenter.  Cm^Experiment . 

Main. Main  0  Spec. Units  the  current  context; 
select  Main' Spec} 

<Promot> 

{Observe  the  creation  of  an  output  window; 
"Elaborating  Viewport^Manager  Body. 
Elaborating  Page^Terzninal  Body. 

It  Works! 

This  is  the  SM  Driver. 

This  is  the  CLI  Driver. 

This  is  the  VT  Driver . " 
appears  in  the  window . } 

2.3.  Experiment  #1  Functionality  Checklist 


Primary  Activities 


Activity 

Version  Control 

Step# 

Supported 

(Y/N) 

Observations 

Create  element . . 

Create  new  version 

.  6 

Yes 

Must  create  the  Ada  object  in  the  Units 
directory  of  the  subsystem  and  place 
under  control  using  the 
Cmvc.Make_Controlled  command. 

Successive . 

.  9 

Yes 

Conventional  checkin/checkout 
paradigm. 

Parallel . 

Retrieve  specific  version 

.  7 

Yes 

Branch  creation  supported  via  the 
Make_Path  and  Make_SubPath 
commands  with  Join^Paths  parameter 
set  to  False. 

Explicit . . 

.  7 

Yes 

Use  the  Cmvc. Revert  command. 

Dynamic . 

Configuration  Control 

Define  system  model 

.  7,9 

Yes 

Defaults  to  most  recent  revision. 

Specify  source  deperxiencies . 

.  5.7.11 

Yes 

Maintained  by  library  and  imports. 

Specify  translation  rules . 

.  5,7.11 

N/A 

Specify  translation  options . 

.  5,7,11 

Yes 

Set  Model  for  subsystem. 

Specify  translation  tools . 

Build  system 

.  5,7,11 

N/A 

Current  default . 

Product  Release 

.  5,7,11 

Yes 

Using  Compilation.  Promote  and 
enumerate  subsystems  comprising  the 
system. 

Baseline  system . 

.  6,7.10 

Yes 

Use  Cmvc.Release  on  each  subsystem 
and  define  an  Activity  for  the  Baseline. 

Create  system  release  class . 

.  11 

Yes 

Create  coded  views  of  all 
subsystems. 
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Secondary  Activities 

Activity  Step  #  Supported  Observations 

Version  Controi 

Merge  variants .  8  Yes  Merge  Ada  objects  which  have  a 

common  ancestor. 


2.4.  Experiment  #2 

1 .  Experiment  setup 

a.  Establish  environment  variables  to  be  used  In  the  experiment. 

{None  are  used;  the  logical  names  assumed  by  the  experiment  are  used  as 
subsystem  names.} 

b.  Change  working  directory  to  the  systemjntegratlon  directory  created  in 
Experiment  #1 . 

{Make  !  Users .  BxperimontBf .  Cin_Experiiiient  the 
current  context . } 

c.  Create  a  new  program  library  named  bulidjib  underneath  the 
sysjntegration  directory. 

{New  libraries,  or  working  views  of  the  subsystems,  will  be  created  as 
needed  later.} 

d.  Confirm  that  no  files  are  currently  reserved: 

Cmvc .  Shotf_Checked_Out_In_Vi«w  (In_View  => 

"  $.[Main,  Vt,Sm,Cli,As].RBv1_Working” , 

Rasponse  => 
"<PROriLE>")  ; 

Cmvc . Show_Checked_Out_In_Viaw ( In_Viaw  => 

"  $.Main.[VttBStBr_working,  ClitBStBr_working, 

SnrtBstBr_working]”)  ; 

e.  Remove  any  pre-existing  copies  of  files  used  throughout  the  experiment. 

{Remove  all  working  and  release  views,  but  allow  configuration  objects  to 
remain.} 
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{Make  !  Users  .  6xperiment6r .  Cin_Experiment 
the  current  context . } 

Cmvc . Destroy_View ( 

What_View  => 

”$.As.[Rev1_0_1, 

Rev1_0_2, 

Rev1_Working]" , 

Demote_Clients  — >  False, 

Destroy_Con£i9uration_Also  — >  False, 

Comments  »> 

Work_Order  =>  "<DEFAULT>", 

Response  =>  "<PROFILE>") ; 

Cmvc . Dest roy_View ( 

What_View  => 

"$.Cli.[Rev1_0_1, 

Rev1_0_2, 

Rev1_Working]")  ; 

Cmvc . Destroy_View ( 

What_View  **> 

"  $.  Main.[Clltester_  Working, 

Rev1_0_1, 

Rev1_0_2, 

Rev1_Working, 

Smtester_  Working, 

Vttester_Working]” ) ; 

Qdqvc  .  Destroy  View  ( 

What_View  => 

"$.Sm.[Rev1_0_1, 

Rev1_1_1, 

Rev1_1_2, 

Rev1_Working]”) ; 

Cmvc . Destroy_VieK ( 

What_VieK  »> 

"$.Vt.[Rev1_0_1, 

Rev1_0_2, 

Rev1_0_3, 

Rev1_Working]”) ; 

2.  Display  configuration  management  historical  information  pertaining  to  the  current 
state  of  the  system.  Measure  time  taken  to  display  history  information. 

Cmvc . ShoK_History_By_Generation ( 

For_Ob  j  e  ct  s  => 

"  $.[Main,  Vt,Sm,Cli,AsJ. Product" , 

Display_Change_Re9ions  — >  True, 

Start ing_Generat ion  s>  1, 

EndLing_Generation  =>  Natural' Last , 

Response  =>  "<PROFILE>" ) ; 

3.  Fetch  all  the  Ada  source  code  files  belonging  to  the  B0.4  baseline  and  build  an 
executable  load  module  named  VerslonO.4.  Measure  time  taken  to  fetch  the  source 
files  in  the  B0.4  baseline.  Measure  time  taken  to  perform  the  build. 

{Display  Activity  B0_4,  note  the  version  numbers  of  the  spec  views  and  load  views 
in  Activity  B0_4,  Invoke  the  Cmvc.Bulld  command  to  reconstruct  all  the  load 
views.  Create  working  views.  Create  Aim_V1_2  to  refer  to  the  new  working  views. 
Set  default  Activity  to  Aim_V1_2.  Execute  main  program.} 
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(Make  !  Users  .  experimenter,  Cm__£xperiment .  B0_4  the 
current  context,  note: 


Subsystem  Spec  View 


Load  View 


As 

Cli 


As_0_Spec 

Cli_0_Spec 


Revl_0_l 
Revl  0  1 


Main 


Sintester_Working 


Sm 

Vt 


Sm_l_Spec 

Vt^O^Spec 


Revl_l_l 
Revl  0  1 


(Make  !  Users  .  experimenter,  Cm^Experiment  the 
current  context . } 

Otnvc.  Build  (Configuration  => 

"  $,[As,  Configurations.  Rev  1_0_  1, 


Cli.  Configurations.  Rev  1J0_1, 

Main.  Configurations.Smtester_  Working, 
Sm.  Configurations.  Rev  1_  1_  1, 
VtConfigurations.Rev1_0_  , 
View_To_Iir^ort  =>  ”  ” , 

Model  *>  ''R1000_Portable'\ 

Goal  =>  ”  Compilation.  Coded'\ 
Limit  «>  "<WORLDS>", 

Comments  »> 

WorkjOrder  =>  "<DErAULTS>" , 
Volume  =>  0, 

Response  =>  "<PROriLE>") ; 


(Due  to  a  bug  in  the  creation  of  configuration-only  mode  and  the  Build  command, 
the  imports  between  the  spec  views  and  load  views  are  lost;  when  the  Build  com¬ 
mand  attempts  to  recompile  the  system  to  coded  state,  the  build  fails.  This  leaves 
the  frozen  releases  in  an  unfrozen  state.  Also,  the  State.Release_History  text  file  is 
lost  from  each  view,  and  must  be  replaced  by  a  dummy  blank  file.} 
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{Replace  Release^History  files. 

Make  !  Users  .  experimenter.  Cm^Experiment . 

As . Revl^O^l . State  the  current  context . } 

<Create  Text> 

Text .  Create  (Iinage__Naxne  =>  "  Release^History^' , 

Kind  =>  Text. File); 

<Promot> 

(A  text  editor  window  opens  on  text  file 
Release__History .  } 

<Enter> 

(Repeat  the  above  steps  in  contexts 
?  Users  .  experimenter.  Cm^Experiment .  Cli . 

Revl^O^l . State , 

f  Users  .  experimenter.  Cm__Experiment .  Main . 

Smtester^Working. State, 

fusers  .  experimenter.  Cm__Experiinent .  Sm. 

Revl^l^l . State,  and 
!  Users  .  experimenter.  Cm_Expe r iment .  Vt . 

Revl^O^l .  State  to  create  a  blank 
Re lease^Hi story  text  file  in  each.} 

{Create  a  working  view  for  each  subsystem;  make 
!  U s er s .  experimenter .  Cm__Exper iment  t he 
current  context . } 

Cmvc.Make_Path(From_Path  =>  Users.experimenter. 
Cm_Experiment.As.Rev1_0_V^ , 

New__Path_Name  => 

Join_Paths  =>  False''); 

Crave .  Make^Path  (From__Path  =>  "  Users. experimenter. 
Cm_Experiment. Cli.Rev1_0_  1 " , 

New_Path_Name  =>  "  Rev2"  , 
Join_Paths  *>  "False"); 

Crave .  Make_P at h  ( Fr om__p at h  =>  "  Users,  experimenter. 
Cm_ExperimentMain.Smtester_Working" , 
New_Path_Name  «>  "  Rev2"  , 
Join__Paths  =>  "False"); 

Cmvc .Makeup at h  (From_Path  =>  "  Users. experimenter. 

Cm_ExperimentSm.Rev1_  1_  1" , 

New_Path_Name  =>  "  Rev2"  , 
Join__Paths  =>  "False"); 

Crave. Make_Path(From_Path  =>  " Users.experimenter. 
Cm_Experiment  VtRev1_0_1" , 

New^Path^Name  =>  "Rev2", 

Join  Paths  =>  "False")  ; 
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{Due  to  problexae  with  the  Build  command,  run 
Cmvc^^Maintenance. Check_Consi5tency  on  the 
working  views  .  Let  !  Users  .  experimenter. 

Cm_Expe r iment  remain  the  current  context . } 
Cmvc__^intenance .  Check__Con8istency  (  Views  => 

”  $.[As.  Rev2_  Working,  Cli.  Rev2_  Working, 
Main.Rev2_Working,  Sm.Rev2_Working, 

Vt  Rev2_  Working]^' , 

Response  =>  ”<PROFILE>”) ; 

{Due  to  problems  with  the  Build  command,  must 
redefine  the  imports  required  to  compile  the 
system.  } 

{Make  !  Users  .  experimenter.  Cm_^Expe r iment  .Main . 
Rev2_Working  the  current  context . } 

Cmvc .  Import  (View__To_Iix^ort  => 

I  Users,  experimenter.  Cm_  Experiment. 
[Sm.Sm_1_Spec,  Vt.Vt_0_Spec, 

Cli_0_SpecJ)  ; 

{Make  !  Users  .  experimenter.  Cm^^Exper iment .  Cli . 
Rev2_Working  the  current  context} 

Cmvc .  Import  ( View_To_Ixr^ort  => 

!Users.experimenter.  Cm_Experiment. 
[Sm.Sm_1_Spec,  Vt.Vt_0_Spec, 

As.As_0_Spec])  ; 

{Make  !  Users  .  experimenter.  Cm_^Experiment .  Sm . 
Rev2_Working  the  current  context) 

Cmvc .  Import  (View__To_Import  => 

lUsers.experimenter.  Cm_Experiment. 

[Vt.  Vt_0_Spec,  As.As_0_Spec])  ; 

{Create  an  Activity  to  refer  to  the  new 
working  views,  make  iTJa^rs ,  experimenter. 
Cm_^Exper iment  the  current  context) 

Act ivity .  Create  ( The_Act ivity  =>  ”  A IM_  V  1_2'' , 
Source  =>  "BCL4”) 
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{Make  f  Users  .  experimenter,  Cm^^Experixxient .  Aim_yi_2 
the  ctirrent  context .  } 

<Object>  I 


Insert (Subsystem 

=> 

”  Main" , 

Load  View 

=> 

"Rev2  Working"); 

<Object>  I 

Insert (Subsystem 

=> 

"  S/77"  , 

Load  View 

=> 

"Rav2  Working") ; 

<Object>  I 

Insert (Subsystem 

=> 

"  Cli" , 

Load  View 

=> 

"Rev2_Working") ; 

<Object>  I 

Insert (Subsystem 

=> 

"  V'f" , 

Load  View 

=> 

"Rev2  Working") ; 

<Object>  I 

Insert (Subsystem 

=> 

"As" , 

Load_yiew 

=> 

"Rev2_Working") ; 

(Save  the  entries  for  the  new  Activity;} 

<Znter> 

Set_De fault  (The_Activity  =>  "Aim_yi_2'^) 

(Rebuild  the  system,  make 
!  Users  .  experimenter,  Cm^Experiment 
the  ctirrent  context .  } 

Compilation . Promote  ( 

Unit  =>  Cli,  Main,  Sm,  Vt]. 

Rev2_Working'' , 

Goal  *>  Compilation.Coded, 

Limit  =>  <ALL_WORLDS>)  ; 

(Link  and  load  the  system  by  executing  it;  make 
! Users  .  experimenter.  Cm  Experiment . Main . 

Re v2^Working. Units  the  ctirrent  context,  and 
select  Main' body.} 

<Promot> 

(Observe  the  creation  of  an  output  window, 
and  Elaborating  Viewport^Manager  Body.", 

"It  works!",  and  "This  is  the  SM  Driver." 
appear  in  the  window. } 

4.  Move  the  Str_Utilities  package  specification  and  body  of  the  current  system  (VI  .0) 
into  the  local  copies  of  the  AIM_SUPPORT  package  specification  and  body. 
Recompile  compilation  units  as  necessary. 

{Checking  Activity  VI  _0  shows  that  release  Rev1_0_2  of  subsystem  AS  would 
have  the  Str_Utilities  package  specification  and  body;  rebuild  subsystem 
As.Rev1_0_2.} 

( Make  !  Us e  r s  .  experimenter .  Cm__Expe  r iment . 

As  the  current  context . } 

Cmvc  .Buiid(Conf  igur  at  ion  =>  "  Configurations.  Rev  1_  0_2*' , 

Model  =>  "fl700CLPorrab/e")  ; 

(Edit  the  Aim_Support  package  specification  to  contain  the  definitions  In  the 
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Str^Utilities  package  specification.  Create  Aim^Support  package  body  to  contain 
the  function  defined  in  Str_Utilities.  Make  Aim_Support  package  body  controlled, 
create  a  new  spec  view  for  subsystem  As.  Change  uses  of  package  Str_Utilities  to 
Aim_Support  in  subsystems  Cli  and  Sm.  Generate  new  spec  view  for  Sm.} 

{Make  !  Users  .  experimenter,  Cm_Experiment . 

As  .  Revl^0^2  .  Units  .  Str^^Utilities '  Spec  the  current 
context . } 

<WindOH>  <Promot> 

{Make  !  Users  .  experimenter,  Cm_Experiment . 

As  .  Rev2^Working.  Units  .Aiin_Support' Spec  the  current 
context . } 

<Check  Out> 

<Install  Unit> 

{Place  cursor  after  subtype  Aiiii_Naixie  definition.  } 

<Object  I> 

{Place  cursor  back  in  Str_Utilities' Spec  window, 
with  cursor  before  type  Str^Access  definition. } 

<Region>  [ 

{Place  cursor  after  function  Get_String  definition.} 
<Region>  ] 

{Note  that  the  two  lines  become  highlighted, 
and  move  cursor  back  to  Aim^Support '  Spec  window.) 

<Region>  C 
<rormat> 

<Promot> 

<Check  In> 

{Make  !  Users  .  experimenter,  Cm_Experiinent . 

As .Revl_0_2 .Units . Str_Utilities' Spec  the  current 
context . } 

<Window>  <Demote> 

{Make  !  Users .  experimenter,  Cm_^Experiment . 

As  .Rev  1_0_2  .Units  .StrJUtilities' Body  the  current 
context . } 

<Window>  <Promot> 

{Place  cursor  before  function  Get  String  definition. } 
<Region>  [ 

{Place  cursor  after  **end  Get_String; '*  statement.) 

<Region>  ] 

{Make  I  Users  .  experimenter,  Cm_Expe r iment . 

As . Rev2_Working . Units  the  current  context . } 

<Create  Ada> 

{Enter: 

"package  body  Aim^Support  is".} 

<rormat> 

{Place  cursor  after  package  body  declaration  in 
!  Users  .  experimenter.  Cm^Exper iment .  As  . 

Rev2^Working .  Units  .  Aim__Support '  body .  } 

<Region>  C 
<Format> 

<Code  Unit> 
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{Make  ?  Users  .  SxpehmentBr.  Cm^Experiment . 

As  .  Revl_0_2  .  Units  .  Str^Utilities '  Body  the  current 
context . } 

<Window>  <Demote> 

{Since  Aim_Support’Body  was  added  to  subsystem  As,  it  must  be  controlled.  The 
configuration  management  system  up  to  this  point  has  assumed  the  existence  of  a 
null  Aim_Support'Body.  An  attempt  to  use  Cmvc.Make_ControIled  to  put  the  new 
actual  Aim_Support'Body  under  version  control  results  in  error  ruessages  and  com¬ 
mand  failure.  The  workaround  for  this  bug  is  to  use  the  Cmvc_Maintenance  com¬ 
mand  Check_Consistency  and  then  make  Aim_Support'Body  controlled.) 

{Make  'Users  .  experimenter.  Cm^Experiment . 

As,  place  cursor  on  Rev2_Working. ) 

Cnxv'C^Malntenance .  Check  Consistency  ( 

Views  =>  "<CURSOR>", 

Response  =>  ”<PROriLE>" ) ; 

{Note:  use  default  values,) 

{Make  !  Users  .  experimenter,  Cm_Experiment . 

As . Rev2_Horking. Units  the  current  context.) 

Cmvc  .Make^Controlled  (What_Ob  ject  => 

”A/n7_Suppo/t'/>od/")  ; 

{Make  !  Users  .  experimenter,  Cm_Experiment . 

Cli . Rev2_Working . Units . 

Command^Interpre ter' Body  the  current 
context . } 

<Check  Out> 

{Select  "with  Str^Utilities "  statement.) 

<Edit> 

{In  edit  window  change  "with  Str^Utilities " 
to  "with  Aim_3upport ”  .  ) 

<Forxnat> 

<Promot> 

<Check  In> 

{Make  !  Users  .  experimenter ,  Cm_Experiment . 

Sm.  Rev2_Working .  Units  .  ImageJManager '  Spec 
the  current  context . ) 

<Check  Out> 

{Select  "with"  clause.) 

<Edit> 

{Delete  "with  Str__Utilities "  .  ) 

<rormat> 

<Promot> 

<Check  In> 

Cmvc .  Make_Spec_yiew  ( 

Spec_View_Pre£ix  =>  "S/Tl2", 

Level  =>  0) ; 

5.  Fetch  the  current  version  (from  baseline  V1.0)  of  the 
COMMANDJNTERPRETER.PERFORM_COMMAND  subprogram.  Measure  time 
taken  to  perform  fetch  operation, 

(Checking  Activity  VI _0  shows  that  release  Rev1_0_2  of  subsystem  CLI  would 
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have  the  subprogram  CommandJnterpreter.Perform_Command:  rebuild  subsys¬ 
tem  Cli.Rev1_0_2.} 

{Make  !  Users  .  exporimenter .  Cin_Ezperijiieiit . 

Cli  the  current  context . } 

Canrc. Build  (Configrirat ion  =>  ” Configurations. Rev1_0_2" , 

Model  =>  ”R1000_Portabie”) ; 

{Copy  Command_lnterpreter.Perform_Command  from  the  VI _0  release  version  of 
subsystem  CLI  to  the  Rev2_Working. Units  version.) 

(Make  !  Users  .  experimenter.  Cm_Experiinent . 

Cli .  Rev2_Working .  Units .  Coxnmand_Interpreter . 

Per£orm_Coianand  the  current  context . } 

<Check  Out> 

Library .  Copy  (Trom  =>  "  iUsers.  experimenter. 

Cm_  Experiment.  Cii.  Rev  1_0_2.  Units. 

Command_  interpreter.Perform_  Command" , 

To  =>  "  iUsers.  experimenter. 

Cm_Experiment.  Cii.  Rev2_  Working.  Units. 

Comrnand_  interpreter.  Perform_  Command" ) 

<Code  Unit> 

<Check  In> 

6.  Generate  an  executable  load  module  named  Product  using  the  Ada  source  files 
presently  in  the  experiment’s  source  code  directory;  perform  this  system  build  using 
the  pragma  SUPPRESS  to  disable  the  following  checks  during  the  translation 
phase: 

.  •  access_check 

•  discriminant_check 

•  index_check 

•  length_check 

•  division_check 

•  overflow_check 

•  elaboration_check 

Measure  time  taken  to  perform  the  buiid. 

(Pragma  SUPPRESS  is  not  supported.) 

7.  Remove  the  configuration  management  file  elements  associated  with  the  specifi¬ 
cation  and  body  of  the  STR_UTILrnES  package.  Measure  time  taken  to  perform 
remove  operation. 

(Make  uncontrolled  and  remove  Str_Utilities  specification  and  body.  Create  new 
spec  views  for  the  subsystem  As  and  Sm.) 
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{Ma3ce  !  Users  .  experimenter,  Cm^Experiment .  As  . 

Rev2  Working. Units  the  current  context.} 

Cmvc  .Make__Uncont rolled  (What^Ob  ject  =>  Str_UtilitieS*SpeC' , 
Comments  =>  ” " ,  Work_Order  =>  "<DErAULT>", 

Response  =>  ”<PROFILE>’')  ; 

{Select  Str^Utilities ' Body . } 

Cmvc  .Make^^Uncont rolled  (What^Object  =>  ”<CURSOR>")  ; 

{No>r  delete  the  body  and  specification; 
select  Str^Utilities' Body . } 

<Object>  d 

{ Select  St r_Ut ilit ies ' Spec } 

<Object>  d 

{Allow  cursor  to  remain  in  context  ! Users. 
experimenter.  Cm^Expe r iment .  As  .  Rev2_Working .  Units  .  } 

Cmvc  .Make_Spec__View  (Spec_yiew_Prefix  =>  ">4s"  , 

Level  =>  1)  ; 

{Make  ?  Users  .  experimenter.  Cm^Experiment .  Sm,  Rev2_Working 
the  current  context. } 

Cmvc  .Make^Spec_yiew  (Spec_yiew_Pref  ix  =>  "S/7t2”)  ; 

{Due  to  a  bug  in  the  Make_Spec_View  command,  the  specification  units  copied  to 
the  spec  view  are  not  automatically  promoted  to  the  state  indicated  by  the  Goal 
parameter.  Visit  the  spec  view  and  promote  the  units  to  coded  state.} 

{Make  !  Users  .  experimenter.  Cm_Exper iment .  As  .  As_l_Spec . 

Units  the  current  context. } 

<Code  (This  World) > 

{Make  ?  Users  .  experimenter.  Cm_Experiment .  Sm.  Sm2_0_Spec . 

Units  the  current  context.} 

<Code  (This  World) > 

(Update  all  the  referencers  of  the  spec  view  of  subsystem  As  and  Sm.} 

Cmvc  ■  Import  (view^To^import  =>  ^  lUsers.experimenter. 
Cm_Experiment.A$.A$_  1_Spec^ , 

into_view  =>  lUsers.experimenten 
Cm_ExperimenL[ 

Cli.[Cli_0_Spec,  Rev2_Working], 

Sm.[Sm2_0_Spec,  Rev2_Workingl 
Main.[Main_0_Spec,  Rev2_Working]]'^ ; 

Cmvc .  Import  (view__To_import  =>  "  fUsers.experimenter. 
Cm_Experiment.Sm.Sm2_0_Spec" , 

into_view  =>  ^\fUser$.experimenter. 
Cm_Experiment.[Main,  Cli].Rev2_Working^')  ; 

8.  Add  prologues  to  all  Ada  source  code  contained  in  the  experiment's  code  directory. 


CMU/SEI-88-TR-21 


37 


{Make  !  Users .  experimenter,  Cm__EacperiiDent .  Vt . 
Re v2^Wor king. Units  the  current  context  and 
place  cursor  on  Vt^Support . ) 

<Mark>  <Begin  Of> 

<Definition> 

<Check  Out> 

<Begin  Of> 

<Object>  I 

{Enter  the  following  in  the  edit  window: 


—  This  is  a  saxx^le  Ada  program  prologue : 

—  Author : 

—  Unit  Name: 

—  Creation  Date : 

—  Update  History: 


) 

<Proo>ot> 

<Chec]c  Xii> 

<Mar]c>  <End  Of> 

{Repeat  the  above  for  all  Ada  Units  in  the  Rev2_Working. Units  areas  of  subsys¬ 
tems  Vt,  As,  Cli,  Sm  and  Main  except  for 
Command_lnterpreter.Perfotm_Command,  which  will  already  have  a  prologue.} 

{To  repeat  the  above  prologue  insertion  procedure, 
the  <Mar]c>  <Begin  0£>  and  <Mar]c>  <End  0£>  commands 
above  have  created  a  macro,  which  now  may  be  bovind 
to  a  key . } 

Editor.  Macro.  Bind  (Key  **>  ”F1”)  ; 

(Now  place  the  cursor  on  any  package  specification 
or  body  while  in  its  enclosing  context,  and  the 
commands  to  insert  the  prologue  template  above 
will  be  repeated  when  the  key  is  pressed. 

<ri>. } 

9.  Construct  a  configuration  baseline  named  V1 .2  of  the  current  system.  In  making 
this  baseline,  each  source  code  file  in  the  experiment’s  code  directory  should  be 
compared  against  the  latest  version  already  baselined  in  version  V1.0;  only  if  the 
local  copy  is  different  (i.e.,  more  up  to  date)  than  the  already  existing  CM  element 
shall  it  be  placed  into  this  new  system  baseline.  Measure  time  taken  to  perform  the 
compare  operations.  Measure  time  taken  to  perform  baseiine  operation. 

(Release  all  of  the  subsystems,  create  Activity  V1_2,  and  create  a  linked  module 
Product_V1_2.} 
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Cinvc .  Release  (From_Working_View  => 

^^$.[Main,  Sm,  Cli,  As,  Vt].rev2_working^^)  ; 

Activity .  Create  (The_Act:ivit:y  => 

Source  =>  ">^/nT_W_2”)  ; 

{Make  !  Users  .  experimenter,  Cm^Expe r iment .  Vl_2 
the  current  context . } 

<Object>  I 


Insert (Subsystem 

*> 

"  Main" , 

Spec__View 

=> 

"Main_0_Spec" , 

Load  View 

=> 

"Rev2_0_1”)  ; 

<Object>  I 

Insert (Subsystem 

=> 

"  Sm" , 

Spec__View 

=> 

"  Sm2_0_Spec" , 

Load  View 

=> 

"Rev2_0_1") ; 

<Object>  I 

Insert (Subsystem 

=> 

"  Cli” , 

Spec__View 

=> 

"  Cli_0_Spec" , 

Load  View 

=> 

"Rev2_0_1") ; 

<Object>  I 

Insert (Subsystem 

=> 

"  vr , 

Spec^View 

=> 

"  Vt_0_Spec” , 

Load  View 

=> 

"  Rev2_0_1") ; 

<Object>  I 

Insert (Subsystem 

=> 

"As”, 

Spec_yiew 

=> 

”As_1_Spec”, 

Load_View 

=> 

"Rev2_1_1”) ; 

{Save  the  changes:} 

<Enter> 

Set_De fault  (The__Activity  => 
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{Make  ! Users  .  experimenter.  Cai_Experixnent 
the  current  context . } 

CJaavc  .Make_Code^View  ( 
rrom_VieK  => 

*'$.[Main.Rev2_0_1,  Sm.Rev2_0  1, 

CIL  Rev2J)_  1,  Vt  Rev2_0_  I 
As.Rev2_1_1]^ , 

Code^yiew^Name  =>  Product_V1_2'')  ; 


Activity  .Create  (The_Activity  =>  ”  Product_Vl_2  ” 
Source  =>  "Aim  VI  2”)  ; 


{Make  !  Users  .  experimenter.  Cm_Experiment . 
Product  VI  2  the  current  context . } 


<Object>  I 
Insert  (Subsystem  => 
Load_yiew  => 
<Object>  I 
Insert  (Subsystem  => 
ZjOad^View  => 
<Object>  I 
Insert  (Subsystem  => 
Load^View  => 
<Object>  I 
Insert  (Subsystem  => 
Load^View  => 
<Object>  I 
Insert  (Subsystem  => 
Load  View  => 


''Product_V1_2'')  ; 


Product_V1_2'')  ; 
"Pruducf_V/7_2")  ; 

ri  ^ 

"Product_V1_2'') ; 


"/As", 

*'Product_V1_2'')  ; 


{Save  the  entries:} 
<Enter> 


{Set  the  default  Activity  to  the  new 
product . } 

Set_De  fault  (The^Activity  »> 

Product_V1_2'')  ; 

{Make  !  Users  .  experimenter.  Cm^Exper intent . 
Main.Main^O^Spec  the  current  context,  and 
select  Main' Spec.} 

<Pramot> 

{Observe  the  creation  of  an  output  window; 
"Elaborating  Viewport_Manager  Body", 

"It  Works!"  and  "This  is  the  SM  Driver." 
appear  in  the  window. } 


2.5.  Experiment  #2  Functionality  Checklist 


Primary  Activities 


Activity 

Version  Control 

Step  # 

Supported 

(Y/N) 

Observations 

Delete  element . 

Create  new  version 

....  7 

Yes 

Use  the  Cmvc.Make_Uncontrolled 
command. 

Derived  . 

Retrieve  specific  version 

....  6 

Yes 

Create  Path,  with  a  different  Model, 

Referential . 

5 

Yes 

Use  the  Cmvc. Revert  command  either 
with  the  version  number  or  a 
negative  number  to  indicate  the 
number  of  previous  versions. 

Compare  different  file  versions . 

Configuration  Control 

Build  system 

....  3 

Yes 

Cmvc.Show_History_By_Generations 
displays  the  change  regions  between 
generations. 

Earlier  release . 

....  3 

Yes 

Either  make  the  appropriate  views  the 
current  context,  or  if  they  were 
destroyed,  reconstruct  using  the 

Cmvc. Build  command. 

Hybrid  . 

Secondary  Activities 

6 

Yes 

Use  the  Cmvc.Accept_Changes 
command  to  collect  the 
latest  objects  among 
joined  working  views. 

Activity 

Version  Control 

Step  # 

Supported 

Observations 

(Y/N) 

Display  history  attributes . 

Product  Release 

1 

Yes 

Display  members  of  a  released  system . 

1 

Yes 

Display  the  Activity  associated 
with  the  release. 

Display  system  release  history . 

1 

Yes 

Cmvc.Show_History_By_Generations 
for  each  of  the  subsystems  in  the 
system. 
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2.6.  Experiment  #1  Answers 

CM1.1  Describe  the  mechanics  of  constructing  a  software  system.  Are  auto¬ 

mated  construction  techniques  supported  (bullt-ln,  Makefile,  command 
procedures)? 

First,  the  system  should  be  partitioned  into  subsystems.  Rational  recom¬ 
mends  that  modules  be  placed  in  subsystems  such  that  there  is  a  minimum 
of  dependencies  crossing  subsystem  boundaries.  The  Cmvc.lnitial  command 
sets  up  the  structure  for  a  subsystem.  Then  Ada  units  may  be  copied  into  or 
created  in  the  Units  subdirectory  of  the  first  worWng  view.  The 
Cmvc.Make_Spec_View  command  is  then  used  to  create  a  view  which 
represents  the  contents  of  a  subsystem  which  may  be  used  by  other  subsys¬ 
tems.  Once  spec  views  have  been  created  for  all  the  subsystems, 
Cmvc.Import  must  be  used  to  allow  an  Ada  unit  in  a  working  view  to  use  an 
Ada  unit  in  another  spec  view.  Once  all  dependencies  between  subsystems 
have  been  established  using  the  Cmvc.Import  command,  an  Activity  should 
be  created.  The  Activity  is  a  list  of  subsystems  with  their  corresponding  spec 
view  version  and  load  (or  working)  view  version. 

Rational  recommends  that  Ada  units,  whether  spec  views  or  load  views,  be 
compiled  as  soon  as  possible,  in  a  compile-as-you-go  fashion.  However, 
complete  system  rebuilds  may  be  accomplished  in  two  different  ways.  Either 
a  Compilation. Promote  command  listing  all  the  subsystems  involved  may  be 
issued,  or  a  Compilation.Promote  command  specifying  a  main  driver  module 
which  uses  all  the  modules  in  all  the  subsystems  may  be  issued. 

The  first  method  was  found  to  be  more  successful  for  the  instantiation  of 
Configuration  Management  Experiments  #1  and  #2.  The  second  method 
would  recompile  only  the  minimum  necessary  for  closure.  When  parameters 
were  set  to  compile  load  views,  Ada  subunits  did  not  get  compiled.  When 
parameters  were  set  to  compile  "subunits  too,"  only  the  specifications  in  the 
spec  views  were  compiled  (and  not  the  contents  of  the  load  views). 

CM1 .2  Elapsed  time  for  performing  a  system  build  operation? 

Forcing  a  complete  system  build,  by  specifying  all  subsystems  to  be  compiled 
in  the  Compilation.Promote  command,  required  43.50  seconds  to  compile 
Rational  source  code  (already  formatted)  to  Rational  code  in  coded  state. 

Creating  coded  views  (no  Diana  tree,  just  machine  code)  of  the  five  subsys¬ 
tems  from  the  subsystems  all  in  coded  state  required  85.64  seconds. 

CM1 .3  Describe  the  mechanics  of  creating  a  CM  element. 

A  subsystem  must  be  created  with  the  Cmvc.lnitial  command.  An  Ada  unit 
must  be  placed  or  created  In  the  Units  subdirectory.  Cmvc.Make_Controlled 
places  the  Ada  unit  under  configuration  management. 

CM1 .4  Describe  the  mechanics  of  constructing  a  configuration  baseline. 

For  this  experiment,  a  configuration  baseline  was  created  by  releasing  each 
of  the  subsystems  with  the  Cmvc.Release  command.  This  creates  a  frozen 
copy  of  the  subsystem,  which  in  turn  can  be  used  to  generate  working  views 
if  modifications  must  be  done  to  the  baseline. 

The  Rational  model  leaves  considerable  latitude,  and  other  methods  for 
baselining  could  be  implemented. 
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CM1.5 


CM1.6 


CM1.7 


CM1.8 


CM1.9 


CM1.10 


CM1.11 


What  kind  of  baselining  mechanism  Is  employed? 

For  this  experiment,  baselines  were  created  by  creating  releases  of  subsys¬ 
tems.  The  command  to  release  a  subsystem  from  working  view  copies  por¬ 
tions  of  the  working  view’s  directory  structure  and  its  Units  subdirectory,  and 
places  them  under  a  "frozen"  status.  A  release  may  be  created  in 
configuration-only  mode,  which  causes  a  copy  of  only  the  configuration  data¬ 
base.  The  Ada  units  can  then  be  reconstructed  using  the  Cmvc.Build  com¬ 
mand.  Configuration-only  mode  can  be  used  in  order  to  save  some  space. 

Subsequently,  working  views  can  be  created  from  the  released  subsystems, 
if  work  must  progress  from  an  "old"  baseline. 

How  are  baselines/releases  tagged  (numeric,  alpha,  alpha-numeric)? 

A  release  of  a  working  view  of  a  subsystem  can  either  be  named  by  the  user 
or  "auto-generated."  The  auto-generated  name  consists  of  the  portion  of  the 
view  name  up  to  "_Working"  followed  by  "_n_m",  where  n  and  m  represent 
automatically  incremented  level  numbers.  The  user  can  control  how  n  and  m 
are  incremented  via  the  level  parameter,  or  through  the  model  world  specified 
when  the  subsystem  was  created. 

If  a  code  view  of  a  subsystem  is  made,  its  name  is  entirely  determined  by  the 
user.  Policy  can  be  established  to  logically  name  code  views  of  subsystems. 

In  this  experiment,  Activities  were  used  to  specify  which  versions  of  the  sub¬ 
systems  formed  a  system  baseline  or  release.  Activities  can  be  given  a 
name  of  any  form.  Policy  can  be  established  to  logically  name  the  Activities. 

Elapsed  time  for  creating  a  CM  file  element? 

Elapsed  time  for  placing  a  file  under  configuration  control  (using 
<Cmvc.Make_Controlled>:  average  time:  2.13  seconds.  The  average  file 
size  for  the  files  in  Rational  Source  Code  state:  3072  bytes  (characters). 

Elapsed  time  for  performing  baseline  operation? 

•  Initial  baseline  for  all  subsystems  -  175.85  sec. 

•  B02,  only  VT  had  to  be  released  -41.15  sec. 

•  B03,  no  release  needed  -  N/A. 

•  B04,  only  SM  had  to  be  released  -  38.13  sec. 

•  VI  .0,  all  subsystems  released  -  201 .51  sec. 

•  VI. 0,  all  subsystems  configuration-only  mode:  -  42.86  sec. 

File  size  Increase  caused  by  baseline  inclusion? 

Releasing  one  subsystem,  SM,  caused  an  increased  disk  usage  of  100,460 
bytes.  Releasing  all  5  subsystems  caused  an  increased  disk  usage  of 
483,609  bytes.  Releasing  all  5  subsystems  in  configuration-only  mode 
caused  an  increased  disk  usage  of  only  51 ,853  bytes. 

How  easy/difficult  Is  It  to  create  a  CM  element? 

Very  easy:  use  Cmvc.lnitial  to  create  the  subsystem  and 

Cmvc.Make_Controlled  to  put  the  Ada  unit  under  version  control  in  the 
Rev1_Working  view  Units  subdirectory. 

How  easy/difficult  Is  It  to  create  a  baseline  configuration?  In  this  exper¬ 
iment,  using  the  Delta  0  release  of  the  Rational  Environment,  creating  a 
baseline  by  releasing  all  the  subsystems  was  easy  using  the  Cmvc.Release 
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CM1.12 

CM1.13 

CM1.14 

CM1.15 

CM1.16 


CM1.17 


command.  However,  editing  an  Activity  to  indicate  the  versions  of  the  sub¬ 
systems  which  form  a  system  release  was  tedious. 

Are  original  files  removed  when  a  CM  file  is  created? 

No,  the  "file"  or  Ada  unit  actually  becomes  the  controlled  element. 

Where  are  the  CM  files  stored?  (separate  directory,  maintained  locally) 

A  copy  of  the  Ada  unit  under  configuration  control  may  be  kept  locally.  A 
copy  of  the  original  unit  is  maintained  in  the  configuration  database  in  the 
subsystem’s  State  subdirectory  in  Cmvc_Database.  When  a  user  edits  the 
Ada  unit,  it  must  be  checked  out  before  it  is  changed.  When  the  user  checks 
the  unit  back  in,  the  deltas  are  stored  in  the  Cmvc_Database. 

How  are  the  CM  flies  stored?  (text,  binary) 

An  Ada  unit  stored  in  a  working  view  or  Released  View  is  stored  as  a 
decorated  binary  tree.  The  Cmvc_Database  maintains  a  copy  plus  the  deltas 
between  checked  in  versions  in  an  unreadable  binary  format. 

Are  the  CM  files  delete  protected? 

The  Ada  units  stored  in  a  working  view  under  configuration  control  are 
protected  from  deletion.  An  attempt  to  delete  an  Ada  unit  under  configuration 
control  raises  a  "Policy  Error."  An  Ada  unit  must  be  removed  from  configu¬ 
ration  control  in  a  working  view  (Cmvc.Make_Uncontrolled)  before  it  can  be 
deleted. 

The  Cmvc_Database  stored  in  the  State  subdirectory  of  a  subsystem  is  NOT 
protected  from  deletion. 

Describe  the  mechanics  of  fetching  a  CM  element 

If  a  view  of  a  subsystem  has  been  stored  in  configuration-only  mode,  the 
view  may  be  reconstructed  by  invoking  the  Cmvc.  Build 
command  with  the  Configuration  pareimeter  set  to  the 
"subsystem_name.configurations.view_name."  Due  to  bugs,  a  dummy  blank 
text  file  named  Release_History  will  have  to  be  created  in  the  subsystem’s 
State  subdirectory.  Cmvc_Maintenance.Check_Consistency  should  be  run 
on  the  rebuild  subsystem  also.  CM  elements  in  the  view’s  Units  directory 
may  then  be  "checked  out"  as  described  below. 

If  a  view  of  a  subsystem  has  not  been  reduced  to  configuration-only  mode, 
then  to  edit  a  CM  element,  make  the  CM  element  or  Ada  unit  the  current 
context,  and  press  one  key — the  <Check  Out>  key.  Also,  the 
Cmvc.CheckjOut  command  can  be  invoked  from  a  command  window: 

<Create  Coiiimand> 

Cxovc. Check  Out 
{Supply  name  of  Ada  Unit 
as  value  for  parameter 
What_Ob ject . } 

<Promot> 

Describe  the  mechanics  of  creating  a  variant  of  a  CM  element. 

A  variant  version  of  a  CM  element  is  created  by  making  a  path  or  subpath  of 
its  subsystem.  The  Cmvc.Make_Path  command,  with  the  Join_Paths 
parameter  set  to  false,  will  allow  the  aeation  of  a  separate  version  of  the  CM 
element,  which  may  be  accessed  simultaneously  with  the  version  in  the  orig¬ 
inal  view.  If  the  Join_Paths  parameter  remains  as  the  default  value  of  true, 
changes  on  the  variant  version  must  occur  either  before  or  after  changes 
made  to  the  original  version. 
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CM1.18 

CM1.19 


CM1.20 


CM1.21 

CM1.22 

CM  1.23 

CM  1.24 

CM1.25 


Describe  the  mechanics  of  fetching  a  variant  of  a  CM  eiement. 

Either  connect  to  the  view  or  path  of  the  variant  version  and  access  the  unit 
as  it  resides  in  the  Units  directory  or  use  the  Cmcv.Revert  command  with  the 
desired  generation  indicated  by  the  To_Generation  parameter. 

Describe  the  mechanics  of  reserving  a  variant  of  a  CM  eiement. 

Make  the  CM  element  or  Ada  unit  the  current  context  and  press  one  key — the 
<Check  Out>  key.  Aiso,  the  Cmvc.Check_Out  command  can  be  invoked 
from  a  command  window: 

<Creat:e  Co(nmand> 

Cntvc .  Check_Out 
{Supply  namve  o£  Ada  unit 
as  value  for  parameter 
What_Ob ject . } 

<Promot> 

Describe  the  mechanics  of  repiacing  a  variant  of  a  CM  eiement. 

With  the  CM  element  or  Ada  unit  that  is  to  be  repiaced  as  the  current  context, 
press  the  <Check  tn>  key.  Aiso,  the  Cmvc.Check_tn  command  can  be  in¬ 
voked  from  a  command  window: 

<Create  coinmand> 

Cmvc . Check_In 
(Supply  name  of  Ada  unit 
as  value  for  parameter 
What_Ob ject . } 

<Promot> 

How  are  CM  fiie  versions  maintained?  (copy,  deitas,  data  compression) 

When  the  Cmvc.Make_Controlled  command  is  first  executed,  a  copy  of  the 
Ada  unit  is  placed  in  the  Cmvc_Database  in  the  State  subdirectory  of  the 
subsystem.  With  each  "check  out"  and  "check  in,"  deltas  are  stored  in  the 
Cmvc_Database. 

Elapsed  time  for  fetching  a  CM  element. 

Elapsed  time  for  fetch  operation  (Check  Out  command):  1 .37  seconds. 
Elapsed  time  for  creating  a  variant  of  a  CM  eiement. 

Elapsed  time  to  create  a  subpath  with  Join_Paths  parameter  set  to  false: 

•  Vttester  -  22.92  seconds 

•  Ciitester  -  23.60  seconds 

•  Smtester  -  22.22  seconds 

Elapsed  time  for  fetching  a  variant  of  a  CM  element. 

Elapsed  time  for  checking  out  various  CM  elements  within  the  subsystems: 

•  Main  - 1.00  seconds 

•  Page_Terminal’Body  - 1.12  seconds 

•  Viewport_Manager’Spec  -1.10  seconds 

•  Viewport_Manager’Body  - 1 .16  seconds 
Eiapsed  time  for  reserving  a  variant  of  a  CM  eiement. 
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No  corresponding  operation  in  the  Rational  Environment. 


CM  1.26 

Elapsed  time  for  replacing  a  variant  of  a  CM  element. 

Elapsed  time  for  checking  in  various  CM  elements  within  a  subsystem: 

•  Main  -  0.96  seconds 

•  Page_Terminal’Body  - 1 .04  seconds 

•  Viewport_Manager‘Spec  - 1 .03  seconds 

•  Viewport_Manager’Body  - 1 .05  seconds 

CM  1.27 

RIe  size  Increase  caused  by  successive  version? 

Size  of  change  to  the  logs  and  the  size  of  the  change  to  the  Ada  unit  are 
stored  in  1024-byte  chunks  in  the  configuration  database. 

CM  1.28 

File  size  Increase  caused  by  variant  version? 

Should  be  same  as  CM  1.27,  above. 

CM  1.29 

How  easy/difficult  Is  It  to  fetch/reserve  a  CM  element? 

Very  easy:  press  one  key,  <Check  Out>. 

CM  1.30 

How  easy/difficult  Is  It  to  replace  a  CM  element? 

Very  easy:  press  <Check  ln>. 

CM1.31 

How  easy/d  Iff  Icult  Is  It  to  create  a  variant  version  of  a  CM  element? 
Relatively  easy,  but  must  be  done  on  the  subsystem  level  with  the 

Make_Path  or  Make_Subpath  command. 

CM  1.32 

How  are  the  reasons  for  version  changes  recorded?  Is  this  mandatory 
or  optional  data  collection? 

Comments  parameter  or  through  work  orders.  The  data  is  optional  but  may 
be  set  to  mandatory  through  the  use  of  work  orders. 

CM1.33 

Can  variant  be  placed  Into  baselines  easily? 

Yes,  copy  the  variant  to  the  desired  subsystems,  and  then  release  the  sub¬ 
system. 

CM  1.34 

Are  fetching/reserving/replacing  variants  harder  than  for  non-variant 
elements? 

No. 

CM1.35 

What  Is  the  default  protection  of  a  fetched  CM  file  element?  Is  the  de¬ 
fault  reasonable? 

"Fetching"  a  CM  file  element  is  accomplished  through  reserving  tokens  in  a 
table.  Read  and  Write  access  are  not  used  on  the  Rational  to  accomplish 
version  control. 

CM  1.36 

What  Is  the  default  protection  of  a  reserved  CM  file  element?  Is  the 
default  reasonable? 

See  CM  1.35. 

CM1.37 

Merging  Is  defined  to  be  the  operation  of  Incorporating  the  changes 
made  In  a  variant  branch  of  a  CM  element  back  Into  the  (current)  main 
trunk  version  of  the  original  root  CM  element.  Describe  the  mechanics 
of  merging  variant  versions  of  a  CM  element. 

Cmvc.Merge_Changes  allows  the  merging  of  Ada  units  in  severed  paths. 
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CM1.38 

CM1.39 

CM1.40 

CM1.41 

CM1.42 

CM1.43 

CM  1.44 

CM1.45 

CM1.46 

CM1.47 


The  Cmvc.Merge_Changes  command  takes  the  name  of  the  unit  to  have 
changes  merged  into  it,  and  the  view  name  of  the  object  whose  changes  are 
to  be  applied. 

The  Cmvc.Accept_Changes  allows  the  merging  of  Ada  units  in  joined  paths. 
The  object  specified  in  the  Destination  parameter  is  changed  to  reflect  any 
modifications  that  have  been  made  to  corresponding  source  objects. 

How  well  are  merge  Inconsistencies  Identified? 

Inconsistencies  are  identified  by  a  text  file  generated  which  is  the  unit  name 
concatenated  with  "_Merging_Report.'  Conflicting  lines  are  marked  with  an 
asterisk  and  semi-colon  (*;)  followed  by  a  number  indicating  which  Ada  unit 
the  line  came  from.  The  report  is  very  clear. 

How  well  are  merge  Inconsistencies  handled? 

Can  edit  the  inconsistencies,  they  show  up  in  a  resulting  Ada  unit  as  lines 
beginning  with  and  a  number. 

Elapsed  time  of  merging  variant  versions  of  a  CM  element. 

Elapsed  time  for  merging: 

•  main.a  into  main:  7.58  seconds 

•  main.b  into  main:  6.17  seconds 

•  main.c  into  main:  5.40  seconds 

Average  elapsed  time  for  merging  variant  versions  of  a  CM  element:  6.38 
seconds. 

RIe  size  Increase  caused  by  merge  operation. 

•  main.a  into  main:  2572  byte  increase 

•  main.b  into  main:  5078  byte  increase 

•  main.c  into  main:  6358  byte  increase 

Total  increase  for  merging  3  variants  back  into  main:  14008  bytes. 

How  easy/d  Iff  I  cult  Is  It  to  merge  existing  variant  versions  of  a  CM  file 
element? 

The  Cmvc.Merge_Changes  command  is  easy  to  use,  and  the  documentation 
is  helpful. 

Describe  mechanics  of  reserving  a  CM  element. 

Make  the  unit  to  be  checked  out  the  current  context  by  traversing  the  subsys¬ 
tem  directory  structure  with  the  <Definition>  and  cursor  movement  keys,  and 
press  the  <Check  Out>  key. 

Describe  mechanics  of  replacing  a  CM  element. 

See  CM1.24. 

Elapsed  time  of  reserving  a  CM  element. 

See  CM  1.26. 

Elapsed  time  of  replacing  a  CM  element. 

Timings  of  <Check  ln>. 

How  easily  do  the  generic  experiments  map  onto  environment 
operations? 
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CM  1.48 

CM1.49 

CM  1.50 

CM1.51 

CM1.52 

CM  1.53 

CM1.54 

CM1.55 

CM1.56 


Easily  mapped,  except  that  the  experiment’s  concept  of  a  "subsystem"  differs 
from  the  Rational  model’s  concept  of  a  "subsystem."  Rational  advocates  that 
subsystems  be  defined  so  that  there  are  few  dependencies  across  subsys¬ 
tem  boundaries. 

How  are  CM  flies  referenced?  (local  name,  CM  file  name) 

"File  Names"  as  well  as  "CM  files"  are  maintained  by  the  system  and  default 
to  the  Ada  unit  name. 

Describe  error  handling  capabilities  and  error  diagnostics. 

The  error  messages  indicate  that  the  CM/VC  commands  are  actually  imple¬ 
mented  through  other  system-level  commands,  and  command  execution 
usually  involves  a  long  stream  of  messages  to  an  execution  window.  Em- 
bedd^  in  these  long  streams  are  error  messages  indicated  by  leading  aster¬ 
isks,  and  sometimes  they  are  not  indicative  of  the  problem. 

[)escribe  the  command  syntax.  Awkward?  Easy  to  learn  and  use? 

Very  consistent  with  the  entire  user  interface  except  in  one  area:  the  Activity 
Editor  is  not  a  "full  screen"  editor  as  are  the  Ada  Editor  and  Text  Editor. 

The  single  keystrokes  for  Check  In  and  Check  Out,  and  the  commands  that 
would  be  used  in  the  day-to-day  development  and  maintenance  of  a  system 
are  easy  to  learn  and  use. 

Multiple  views  of  a  software  system  In  this  context  Is  defined  to  be  the 
capability  of  representing  the  software  system  from  differing  perspec¬ 
tives  (e.g.,  functional  subsystems  versus  baselined  product  class).  Are 
multiple  views  of  a  product  supported?  Is  concurrent  use  supported? 

Yes,  many  different  working  views  of  subsystems  can  exist  at  the  same  time. 
The  nrodel  allows  different  activities  to  pick  up  different  sets  of  released  and 
working  views.  Multiple  views  cind  concurrent  use  are  both  supported.  The 
model  allows  for  great  flexibility,  or  policies  can  be  established  and  enforced. 

Is  the  CM  capability  Integrated  Into  the  compilation  system? 

Yes,  a  given  Ada  unit  exists  in  source,  installed,  or  coded  state  and  can  be 
checked  in  or  checked  out  in  any  of  these  states,  although  it  is  recommended 
that  a  successful  compilation  (or  coded  state)  be  reached  before  the  Ada  unit 
is  checked  in. 

Describe  Ada  filename  syntax. 

RIenames  are  maintained  by  the  system  and  are  the  Ada  unit  name.  Any 
valid  Ada  unit  name  is  a  valid  "Ada  filename." 

Does  all  source  code  have  to  be  In  the  same  directory  or  Is  a  hierar¬ 
chical  project  structure  supported? 

No,  source  code  can  be  maintained  in  several  subsystems,  or  a  hierarchical 
project  structure  can  be  supported  by  subdirectories  residing  under  the  units 
directory  of  a  subsystem.  In  the  Delta  0  release,  a  hierarchy  of  subsystems 
is  not  supported. 

What  mechanism  Is  used  for  sharing  program  libraries? 

Links  and  imports  (which  are  actually  built  on  top  of  and  used  to  maintain 
links  among  subsystems). 

Can  a  package  spec  and  body  be  separated  In  different  program 
libraries? 

No.  However,  a  copy  of  the  spec  goes  into  the  spec  view  to  allow  for  minimal 
recompilation  and  provide  for  "firewalling"  between  subsystems. 
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What  Intermediate  files  are  generated  by  the  compilation  system? 

None,  an  Ada  unit  moves  between  states,  as  the  Diana  Tree  becomes  more 
or  less  decorated. 


2.7.  Experiment  #2  Answers 


Question 

CM2.1 


CM2.2 

CM2.3 


CM2.4 

CM2.5 

CM2.6 

CM2.7 


Response 

Describe  the  mechanics  of  displaying  history  Information  for  a  CM 
element. 

There  are  a  number  of  Show  commands: 

•  Show 

•  Show_AII_Checked_Out 

•  Show_AII_Controlled 

•  Show_AII_Uncontrolled 

•  Show_Checked_Out_By_User 

•  Show_Checked_Out_ln_View 

•  Show_History,  Show_History_By_Generations 

•  ShowJmage_Of_Generation 

•  Show_Out_Of_Date_Objects 

All  of  these  are  invoked  from  a  command  window. 

□apsed  time  for  displaying  history  Information  for  a  CM  element. 

The  elapsed  time  for  Show_History_By_Generations  for  all  the  Ada  units  was 
33.03  seconds.  This  is  approximately  2  seconds  for  each  unit. 

Describe  the  mechanics  of  rebuilding  an  earlier  baselined  system. 

Invoke  the  Cmvc.Build  command  with  the  parameter  configuration  set  to  the 
subsystem  name  concatenated  with  ".Configurations."  and  the  view  name. 
Due  to  bugs  in  the  configuration-only  mode  and  the  Build  command,  a 
dummy  text  file  named  Release_History  must  be  created  in  the  State  direct¬ 
ory.  It  is  also  advised  to  invoke  Cmvc_Maintenance.Check_Consistency  on 
the  view.  The  bug  also  affects  imports  that  are  lost  between  subsystems  and 
must  be  respedfied.  The  units  in  the  subsystems  must  also  be  recompiled. 

Elapsed  time  for  rebuilding  an  earlier  baselined  system. 

From  a  configuration-only  mode,  the  Cmvc.Build  command  required  133.81 
seconds:  and  24.10  seconds  elapsed  for  a  recompilation  of  the  system 
across  the  five  subsystems.  Rebuilding  the  earlier  baselined  system  required 
a  total  elapsed  time  of  157.91  seconds. 

Describe  mechanics  of  fetching  a  CM  element. 

Refer  to  answer  CM  1.1 6. 

Elapsed  time  for  fetching  a  CM  element. 

Refer  to  answer  CM1 .22. 

Describe  mechanics  of  deleting  a  CM  element. 
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Invoke  the  Cmvc.Make_Uncontrolled  procedure  with  the  parameter 
What_Object  set  to  the  name  of  the  Ada  unit  to  be  deleted.  Then  invoke  the 
Library. Delete  procedure  with  the  parameter  Existing  set  to  the  name  of  the 
Ada  unit  to  be  deleted. 

CM2.8  Elapsed  time  for  deleting  a  CM  element. 

Elapsed  time  to  make  an  Ada  unit  uncontrolled:  1 .71  seconds. 

CM2.9  Describe  mechanics  of  comparing  different  versions  of  a  CM  element. 

The  Show_History_By_Generations  procedure  provides  a  list  of  change 
regions  between  versions. 

CM2. 1 0  Elapsed  time  for  comparing  different  versions  of  a  CM  element. 

Not  applicable. 


2.8.  Configuration  Management/Version  Control  (CM/VC) 

Analysis 

Although  the  problems  are  many  in  number,  they  do  not  represent  a  serious  performance  prob¬ 
lem  for  the  Delta  0  Release  of  the  configuration  management  and  version  control  system.  Ra¬ 
tional  Customer  Support  was  very  prompt  in  acknowledging  the  problems  and  suggesting 
workarounds. 

2.8.1.  Functionality 

The  instantiation  of  Experiments  #1  and  #2  reflects  one  workaround  required  by  a  bug  in  the 
system:  A  combined  load  view  could  not  be  released.  When  releasing  combined  load  views, 
which  contain  elements  that  depend  on  each  other,  the  Release  command  goes  into  an  infinite 
loop.  The  transcripts  for  Experiments  #1  and  #2  also  reflect  some  workarounds  for  other  bugs 
present  in  the  Delta  0  Release  of  the  CMA/C  software.  Rrst,  when  a  spec  view  is  created  from  a 
load  view,  a  parameter  Goal  defaults  to  compilation  state  Coded.  The  compilation  of  specifi¬ 
cations  to  coded  state  does  not  occur  when  the  spec  view  is  created.  As  such,  the  user  must  go 
to  the  newly  created  spec  view  working  units  subdirectory  and  compile  these  units  as  a  separate 
step.  Second,  due  to  a  bug  in  the  creation  of  a  subsystem  release  in  configuration-only  mode 
and  the  Build  command,  the  imports  defined  between  spec  views  and  load  views  were  lost. 
When  the  Build  command  attempted  to  recompile  the  system  to  coded  state,  it  failed.  This  left 
the  released  subsystems  that  were  supposed  to  be  frozen  in  an  unfrozen  state.  Several  steps 
must  be  taken  to  reestablish  the  lost  import  information.  Also,  each  view  loses  its 
State. Release_History  text  file.  As  such,  copies  of  the  views  cannot  be  made  by  the  Make_Path 
or  Make_SubPath  commands.  The  work  around  consists  of  visiting  the  State  subdirectory  and 
editing  in  a  blank  Release_History  text  file.  The  loss  of  this  file  represents  a  potential  loss  of 
information  if  comments  are  provided  to  the  Release  command. 

The  functionality  presented  by  the  configuration  management  and  version  control  system  pro¬ 
vides  all  of  the  "Primary  Activities"  and  "Secondary  Activities"  outlined  in  the  functionality  check¬ 
lists  for  Experiments  #1  and  #2.  Specifying  translation  rules  as  in  a  Unix  Makefile  does  not  apply 
to  the  Rational  Environment  compilation  strategy.  Translation  rules  and  order  are  maintained 
automatically  as  interdependency  information  by  the  directory  structure  of  the  Rational  Environ- 
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merit.  As  such,  translation  rules  are  not  needed.  Translation  tools  do  not  need  to  be  specified, 
since  one  command  procedure,  Compilation. Promote,  with  the  proper  parameters  handles  trans¬ 
lation.  The  Rational  Environment  provides  a  very  complete  set  of  CM/VC  functionality  as  detailed 
by  the  SEI  Evaluation  Method  ior  the  development,  maintenance,  and  release  of  software. 

2.8.2.  Performance 

From  the  perspective  of  a  programmer  using  the  CMA/C  system,  the  most  commonly  used  com¬ 
mands,  such  as  "Check  In"  and  "Check  Out,"  are  fast  and  easy  to  use  interactively.  System 
response  for  these  common  commands  generally  only  required  about  one  second  of  elapsed 
time.  Some  of  the  less  common  commands,  which  would  probably  be  invoked  only  by  project 
leaders  or  managers,  required  more  time.  The  elapsed  time  for  performing  a  baseline  operation 
across  all  five  subsystems  required  over  two  minutes.  When  the  baseline  was  released  in 
configuration-only  mode,  which  would  require  that  it  be  rebuilt  later  if  needed,  the  elapsed  time 
required  was  under  a  minute.  The  time  required  for  releasing  a  system  would  increase  with  the 
size  (number  of  lines  of  Ada  code)  of  the  system.  For  the  system  presented  by  the  experiments, 
an  initial  system  build  required  a  total  elapsed  time  of  slightly  over  two  minutes. 

The  initial  creation  of  an  empty  subsystem  consumed  105,814  bytes.  Constructing  releases, 
paths,  and  subpaths  of  a  subsystem  is  by  its  nature  also  an  expensive  operation,  as  almost  the 
entire  subsystem  directory  structure  is  copied.  A  disk  utilization  increase  of  about  100,000  bytes 
was  noted  for  each  subsystem  when  a  release  was  made.  A  subsystem  may  exist  in 
configuration-only  mode,  which  does  return  some  disk  space  to  the  file  system.  A  return  of  almost 
80,000  bytes  of  available  storage  was  noted  when  one  view  of  a  subsystem  was  destroyed  and 
left  in  configuration-only  mode.  (Configuration-only  mode  would  allow  the  subsystem  to  be  rebuilt 
if  needed.) 

2.8.3.  User  Interface 

The  user  interface  to  the  configuration  management  and  version  control  commands  is  the  same 
interface  as  that  used  by  all  system  commands.  The  commands  are  actually  calls  to  Ada  proce¬ 
dures.  The  procedures  are  invoked  from  a  command  window,  which  provides  context  and  a 
begin-end  block  in  which  to  insert  the  command.  Command  completion  and  the  presentation  of 
default  parameters  are  very  useful  in  these  procedures.  Although  the  configuration  management 
and  version  control  commands  have  the  bugs  previously  noted  and  the  problems  described  in  the 
following,  the  most  commonly  invoked  commands  are  easy  to  use  and  bound  to  the  program 
function  keys. 

Version  control  is  only  available  in  the  context  of  the  subsystem  structure.  Objects  placed  in  a 
subsystem  must  be  controlled  explicitly  when  they  are  first  placed  in  the  subsystem.  Subsequent 
copies  of  the  view  created  through  the  Make_Path  or  Make_SubPath  will  continue  the  object  as  a 
controlled  object.  However,  if  access  to  the  objects  is  not  controlled,  they  are  lost  if  the  subsys¬ 
tem  is  ever  reduced  to  configuration-only  mode.  In  this  case,  a  simple  oversight  on  the  part  of  the 
user  can  have  disastrous  results  over  the  life  cycle  of  a  subsystem. 

The  editor  provided  for  creating  and  changing  Activities  differs  from  the  whole  screen  editor  pro¬ 
vided  for  Ada  Objects  or  command  windows.  The  Activity  Editor  actually  involves  providing 
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parameters  to  procedures  such  as  Activity  .Add  and  Activity.  Change  to  add  or  change  the  con¬ 
tents  of  an  Activity,  it  aiso  requires  pressing  <Enter>  to  save  changes,  if  this  is  not  done, 
changes  are  not  saved,  which  often  ieads  to  unexpected  performance.  The  Activity. Create  com¬ 
mand  requires  the  vaiue  of  parameter  The_Activity  to  be  suppiied  as  a  text  string.  The  prompt  for 
this  vaiue  suppiies  quotes  that  persist  once  the  user  has  typed  in  a  string.  The  optionai 
parameter  Source  requires  the  same  type  of  vaiue  as  The_Activity,  yet  the  user  is  not  provided 
with  quotes  that  persist  once  the  user  has  typed  in  a  string.  Aiso,  if  quotes  are  not  typed,  then  the 
resuiting  error  message  is  misleading; 

Parameter  list  (THE_ACTIVITY  =>  "B0_2",  SOURCE  =>  B0_1, 

MODE  =>  ACTIVITY. EXACT_COPY,  ...)  is  invalid. 

This  is  accompanied  by  an  underscore  appearing  in  the  command  window  after  "Activity. Create" 
and  underneath  the  parameter  value  B0_1 . 

View  names  cannot  have  underscores.  This  seems  inconsistent  since  the  view  name  is  con¬ 
catenated  with  "_Working"  and  used  as  a  directory  name.  Directories  that  are  created  using  the 
reguleir  directory  creation  commands  do  not  have  this  restriction  and  can  use  any  characters 
permitted  in  an  Ada  name.  The  restriction  stems  from  the  inability  of  the  Build  command  to 
reconstruct  a  view  with  extra  underscores  in  the  name. 

The  configuration  management  and  version  control  packages  were  released  for  the  first  time  in 
the  Rational  Environment  Delta  0  Release.  The  bugs  encountered  and  the  problems  with  the 
user  interface  reflect  the  immaturity  of  these  packages. 

2.8.4.  System  Interface 

The  configuration  management  and  version  control  facility  is  completely  integrated  with  the  editor, 
browser,  and  compiler  of  the  Rational  Environment.  It  does  not  make  use  of  access  control 
facilities.  The  user  is  expected  to  construct  "skins"  which  tie  together  the  work  order  manage¬ 
ment,  configuration  management  and  version  control,  and  access  control  facilities  to  reflect  user 
policy  for  the  system  being  created,  tested,  or  maintained. 
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3.  System  Management  Experiments 


3.1.  introduction 

System  Management  Experiment  #1  investigates  the  procedures  supporting  the  installation  of  an 
Ada  software  environment.  The  experiment  requires  the  collection  of  information  about  loading 
the  software  from  release  media,  integrating  the  software  with  the  underlying  operating  environ¬ 
ment,  and  exercising  the  installed  environment. 

The  R1000  computer,  the  Rational  Environment  for  Ada  development,  and  a  Rational  service 
contract  are  a  package.  (Although  the  service  contract  is  a  separately  priced  item.  Rational 
strongly  recommends  it.)  As  part  of  the  service  contract.  Rational  technicians  perform  all  system 
software  installation  and  updating.  Also,  the  software  does  not  need  to  be  integrated  with  an 
underlying  operating  environment,  as  in  a  more  traditional  APSE.  For  these  reasons,  and  be¬ 
cause  the  other  experiments  exerdse  the  installed  environment.  Experiment  #1  was  not  con¬ 
ducted  on  the  Rational  Environment. 

System  Management  Experiment  #2  investigates  the  support  of  user  account  management  activi¬ 
ties.  The  operations  of  creating,  deleting,  modifying,  copying,  displaying,  and  verifying  user  ac¬ 
count  information  are  outlined  in  the  experiment  and  instantiation  in  Section  3.2.  Because  the 
only  system  management  attributes  assodated  with  an  account  are  account  name,  password, 
and  user  group,  some  of  the  steps  in  the  experiment  are  not  applicable  to  the  Rational  Environ¬ 
ment.  However,  many  attributes  and  operations  for  work  space  management  can  be  assodated 
with  an  individual  account  by  the  Rational  Environment,  including  key  bindings,  maao  definitions, 
session  switches,  and  so  forth.  However,  these  attributes  and  operations  roughly  correspond  to 
the  workspace  customization  that  can  be  performed  by  a  VAXA/MS  login  file,  not  the  system 
management  attributes  required  by  this  experiment. 

System  Management  Experiment  #3  does  not  contain  individual  steps  and  data  collection.  It  is 
an  assimilation  of  questions  that  address  the  issues  of  maintaining  current  releases  of  the  Ada 
environment  software,  customer  support  and  service,  and  archiving  (and  subsequently  retrieving) 
the  Ada  environment  software  and/or  database  elements.  These  questions  are  presented  and 
answered  in  Section  3.6. 

System  Management  Experiment  #4  investigates  the  procedure  for  the  collection  of  accounting 
statistics.  The  experiment  addresses  the  issues  of  monitoring  the  system’s  performance  and 
collecting  specific  accounting  information;  CPU  usage,  disk  space  usage,  connect  time,  and 
number  of  pages  printed.  The  experiment  requires  the  development  of  procedures,  one  to  auto¬ 
mate  the  collecting  of  system  accounting  statistics  and  one  to  facilitate  dynamic,  continuous 
monitoring  of  system’s  performance.  Neither  of  these  procedures  had  to  be  written  for  the  exper¬ 
iment,  since  the  Rational  Environment  supplies  this  functionality,  as  detailed  in  Section  3.4. 

In  the  following  instantiation  of  the  experiments,  specific  keys  to  be  pressed  are  denoted  by  the 
lettering  on  the  key  or  key  map  designation  enclosed  in  angle  brackets  (<  >.)  The  first  time  a 
command  is  presented  in  text,  all  its  parameters  are  detailed.  Parameters  that  must  be  supplied 
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or  changed  are  printed  in  italics.  Subsequent  uses  of  the  command  include  only  required 
parameters  and  those  that  differ  from  the  default.  Familiarity  with  creating  and  executing  a  com¬ 
mand,  selecting  an  object,  traversing  objects  in  a  window,  and  moving  between  windows  is  as¬ 
sumed.  Any  variation  in  reporting  the  experiment  step  is  noted. 


3.2.  Experiment  #2 

1 .  Experiment  setup 

a.  Log  in  to  environment  as  the  system  administrator. 

{The  R1000  does  not  have  system  administrator  accounts.  Members  of 
group  Operator  (user  name  Operator)  and  users  with  write  access  to  file 
!Machine.Operator_CapabiHty  can  perform  operations  within  the  Environ¬ 
ment  that  require  operator  capability.  Log  in  to  an  account  with  operator 
capability,  in  this  case  Operator.  System  prompts  are  in  bold  type  and  the 
user  response  is  in  italics.} 

Name:  Operator  <return> 

Password:  {enter  the  password}  <return> 

Session:  <retum> 

b.  Create  subdirectory  in  which  experimental  results  will  be  stored. 

(Results  gathered  by  using  the  timeit  and  record_size  procedures  are  re¬ 
ported  to  a  standard  output  window.  These  programs  are  listed  in  Appendix 
A  with  an  explanation  of  their  use.} 

c.  Establish  environmental  variables  to  be  used  in  the  experiment. 

(None  are  used.} 

2.  Create  environment  user  account  group  name  ENV_USER.  Measure  time  taken  to 
create  new  user  account  group.  Record  file  size  increase  caused  by  creating  a  new 
user  account  group. 

Creato_Group  (Group  =>  "  Env_User”  , 

Response  =>  "<PROFILE>") ; 

(Note:  Access  control  groups  are  maintained  in  a  directory  IMachine.Groups,  this  is 
what  should  be  measured  for  the  increase  in  size  caused  by  creating  a  new  user 
account  group.} 

3.  Create  environment  user  account  for  John  T.  Smith;  assume  the  last  name  is  to  be 
used  for  the  user  name,  password,  and  pathname  of  the  account's  home  directory. 
Measure  time  taken  to  create  new  user  account.  Record  increase  in  file  size 
caused  by  creating  a  new  user  account. 

(The  R1000  environment  automatically  assigns  the  path  or  context  "lUsers. /Vame" 
to  the  home  directory  of  a  new  user  Name.) 

Create_Usor (User  =>  "Smith", 

Password  =>  "Smith", 

Volume  =>  0, 

Response  =>  ”<PROFILE>") ; 

4.  Add  user  Smith  to  user  group  ENV_USER.  Measure  time  taken  to  add  new  user  to 
an  account  group.  Record  increase  in  file  size  caused  by  adding  new  user  to  an 
account  group. 
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Add._To_Group  (User  =>  "Smith", 

Group  =>  "EnvJUser, 

Response  =>  "<PROFILE>") ; 

5.  Copy  Smith  account  characteristics  into  a  new  account  for  Thomas  R.  Jones;  as¬ 
sume  the  last  name  is  to  be  used  for  the  user  name,  password,  and  pathname  of 
the  account’s  home  directory.  Measure  time  taken  to  copy  characteristics  into  a 
new  user  account.  Record  increase  in  file  size  caused  by  creating  a  new  user 
account. 

{The  Rational  environment  has  no  provision  for  copying  accounts.  Create  user 
Jones  as  in  step  SM2.3  and  SM2.4.) 

Create_nser  (  User  =>  ”  Jones”  , 

Password  =>  "Jones”)-, 

Add_To_Group  (User  =>  "Smith", 

Group  =>  "EnvJUser, 

Response  =>  "<PROriLE>") ; 

6.  Copy  Smith  account  characteristics  into  a  default  account  named  DEFAULT  to  be 
used  in  the  future  for  creating  new  environment  accounts.  Measure  time  taken  to 
copy  characteristics  into  a  new  user  account.  Record  file  size  increase  caused  by 
creating  a  new  user  account. 

(The  only  default  account  characteristic  in  the  Rational  Environment  is  the 
password.  Access  to  certain  groups  is  added  later.  Below  are  the  details  showing 
how  to  create  an  Ada  program  Create_Default_Account.  When  this  program  is  run 
from  an  account  with  operator  capability,  with  no  user  name  provided,  it  will  create 
a  user  DEFAULT  with  password  "defaulf  and  place  the  user  in  group  ENV_USER.} 

<Create  Ada> 

Create_Default_Account 

<Promot> 

{Enter  the  following  in  the  edit  window, 
which  opens : } 
with  Operator; 

procedure  Create_Default  Account 

(Name  : String  =:  "Default”)  is 

begin 

Operator. Create_User (User  =>  Name, 

Password  s>  Name, 

Volume  =>  0, 

Response  ->  "<PROFILE>" ) ; 

Operator .Add_To_Group (User  =>  Name, 

Group  =>  "Env_User, 

Response  =>  "<PROFILE>") ; 
end  Create_Default  Account; 

(Type  the  following  to  coa^ile  and  store  the 
program; } 

<Promot> 

<Promot> 

<Enclosing> 

(Create  default  account  DEFAULT  by  executing  the  procedure  just  created.} 

(Check  that  Create_pefault_Account ' body  is  selected.) 
<Promot> 
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7.  Disable  logins  for  the  DEFAULT  account.  Measure  time  taken  to  disable  logins  for 
an  account. 

Delete_Dser (User  =>  "DEFAULT", 

Response  =>  "<PROFILE>") ; 

8.  Display  characteristics  of  the  DEFAULT  account.  Measure  time  taken  to  display 
account  characteristics. 

{Cannot  display  account  characteristics  of  a  disabled  account.} 

9.  Change  account  name  of  the  DEFAULT  account  to  be  ENV_USER.  Measure  time 
taken  to  modify  one  characteristic  of  a  user  account.  Record  increase  in  file  size 
caused  by  modifying  a  characteristic  of  a  user  account. 

{No  procedure  provided  to  change  an  account  name.} 

1 0.  Display  characteristics  of  the  DEFAULT  account.  Measure  time  taken  to  display 
account  characteristics. 

{See  step  8.} 

1 1 .  Modify  account  names  as  above  (step  9)  for  the  Smith  and  Jones  accounts. 
Measure  time  taken  to  modify  one  characteristic  of  a  user  account.  Record  file  size 
increase  caused  by  modifying  a  characteristic  of  a  user  account. 

{One  account  characteristic  which  can  be  modified  is  the  password.} 

Chsnge_Pas  sword  (User  *>  "Smith", 

01d._Password  *>  "Smith", 

New_Pas sword  =>  "  newsmith" , 

Response  =>  "<PROFIIJ:>")  ; 

Change_Password  (User  =>  "Jones", 

01d_Pas sword  =>  "JoneS", 

Kew_Password  =>  "newjones”); 

1 2.  Display  characteristics  of  the  Smith  and  Jones  accounts.  Measure  time  taken  to 
display  account  characteristics. 

Display  Group  (Group  »>  "Smith", 

Response  =>  "<PROFILE>") ; 

Display_Group (Group  =>  "JoneS"); 

13.  Create  an  account  for  Jane  Doe  using  characteristics  from  the  DEFAULT  account; 
assume  the  last  name  is  to  used  for  the  user  name,  password,  and  pathname  of  the 
account’s  home  directory.  Measure  time  taken  to  copy  characteristics  into  a  new 
user  account.  Record  file  size  increase  caused  by  creating  a  new  user  account. 

Create_De£ault_Account (Name  »>  " Doe" )  ; 

14.  Create  working  directories  containing  login/logout  command  procedures  for  the 
Smith,  Doe,  and  Jones  accounts.  Measure  time  taken  to  create  initial  account 
directories. 

{The  Rational  Environment  command  that  aeates  accounts  automatically  aeates  a 
user  home  directory  with  the  pathname  lUser.user  name.  This  was  performed  in 
steps  3,  5  and  13.} 

15.  Update  any  environment-specific  databases  to  grant  Smith,  Doe,  and  Jones  ac¬ 
cess  to  the  environment  software. 

{Since  the  Rational  Environment  is  not  a  system  layered  on  top  of  a  traditional 
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environment  commands  to  create  a  user  account  automatically  provide  access  to 
the  environment.  Steps  3.  5  and  13  have  already  accomplished  this.} 

16.  Verify  the  creation  and  correctness  of  the  Smith,  Doe,  and  Jones  accounts  (e.g., 
login  and  edit  a  text  file  from  these  accounts). 

{Log  off  the  RIOOO  account  Operator} 

<Hoxne  Library> 

<Create  Comma n<i> 

Quit 

<Promot> 

(Log  in  as  Smith .  System  prompts  are 
in  bold  type^  and  user  response  is 
in  italics . } 

User:  Smith  <Return> 

Password:  Smith  <Return> 

Session:  <Return> 

(Create  a  text  file.} 

<Create  Text> 

My_file 

(In  edit  window,  which  opens,  type;} 

This  is  a  text  file . 

(Store  the  text  file.} 

<Enter> 

(After  My  file  appears  in  the  Smith  home 
directory,  log  out.} 

<Create  Coixsnand> 

Quit 

<Proniot> 

{Repeat:  the  above  steps  for  the  accounts 
Doe  (password:  Doe)  and  Jones 
(password:  newjones) . } 

1 7.  Revoke  environment  access  from  the  Jones  account.  Measure  time  taken  to 
revoke  environment  access  from  a  user’s  account. 

Delete_User (User  =>  "Jones”)  ; 

18.  Remove  Jones  account  from  the  ENV_USER  account  group.  Measure  time  taken 
to  remove  user  from  an  account  group.  Record  decrease  in  file  size  caused  by 
removing  user  from  an  account  group. 

Reinove_rrom_Group  (User  =>  "JoneS", 

Group  =>  "Env_User, 

Response  =>  "<PROriLE>" ) ; 

1 9.  Remove  Jones  account.  Measure  time  taken  to  remove  user  account.  Record 
decrease  in  file  size  caused  by  removing  user  account. 

Library  .Destroy  (Existing  =>  "  iUsers.Jones??"  , 

Threshold  =>  1, 

Limit  =>  "<DIRECTORIES>"  , 

Response  =>  "<PROFILE>" ) ; 
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3.3.  Experiment  #2  Functionality  Checklist 


Activity 

Step  # 

Supported 

(Y/N) 

Observations 

User  Account  Management 

Create  user  account . 

.  3,13 

Yes 

Delete  user  account . 

.  19 

Yes 

Copy  user  accounts . 

.  5 

No 

Add  user  account  to  group . 

.  4 

Yes 

Delete  user  account  from  group . 

.  18 

Yes 

Establish  user  account  characteristics . 

.  3,5,13 

Yes 

Only  system  management  characteristic 
is  the  account  password.  Membership 
in  a  user  group  is  added  later. 

Modify  user  account  chars . 

.  11 

Yes 

Password  and  group  membership. 

Establish  default  account  chars . 

.  6 

No 

Can  create  a  program  to  build  default 
account. 

Modify  default  account  chars . 

.  9 

No 

Display  user  account  chars . 

.  12 

Yes 

Can  display  group  membership. 

Display  default  account  chars . 

.  8,10 

No 

Create  initial  working  directories . 

.  14 

Yes 

Default  working  directories  are  created 
automatically  by  the  create  user  account 
procedure. 

Establish  default  login/logout  macros . 

.  14 

No 

Default  system  wide  login  procedures 
(which  can  be  changed)  are 
automatically  used  for  all  users  who 
do  not  override  them  with  procedures 
in  their  home  directory. 

Verify  creation  of  user  accounts . 

.  16 

Yes 

3.4.  Experiment  #4 

1 .  Experiment  setup 

a.  Log  in  to  underlying  operating  system  as  the  system  administrator. 

{The  Rational  Environment  has  no  system  administrator  account.  There¬ 
fore,  log  in  as  an  ordinary  user  and  acquire  operator  capability.} 

b.  Create  subdirectory  in  which  experimental  results  will  be  stored. 

(As  will  be  seen,  this  experiment  generates  no  results  to  be  logged.} 

c.  Establish  environment  variables  to  be  used  in  the  experiment. 

(None  are  used.} 

2.  Establish  default  access  control  to  restrict  non-privileged  users’  access  to  all  com¬ 
mand  files  and  log  files  to  be  used  for  System  Management  activities. 

(The  Delta  Release  of  the  Rational  Environment  already  restricts  access  of  non- 
privileged  users  to  system  management  commands  by  requiring  operator  capability 
for  certain  commands.} 
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3.  Create  a  subdirectory  named  BILLINGS  under  the  system  root  directory  to  house 
environment  accounting  statistics. 

{The  directory  name  for  accounting  information  is  hardwired  into  the  Rational  Envi¬ 
ronment  as  !Machlne.Accountlng.} 

4.  Initially,  enable  the  logging  of  environment  accounting  information.  Measure  time 
taken  to  enable  logging  of  accounting  information. 

•  CPU  usage 

•  Connect  time 

•  Disk  usage 

•  Number  of  logins 

•  I/O  activity 

•  Pages  printed 

{Usage  logging  in  the  Rational  Environment  is  always  enabled.  Usage  accounting 
is  monolithic:  there  is  no  separate  enabling  of  accounting  for  different  resources.} 

5.  Write  a  command  procedure  to  automate  the  monthly  collection  of  accounting  infor¬ 
mation  to  be  used  by  a  billing  program,  assuming  logging  is  already  enabled. 
Measure  time  taken  to  disable  system  logging.  Record  size  of  system  accounting 
log  file. 

(The  current  accounting  file  cannot  be  renamed,  moved,  or  copied  while  the  system 
has  a  lock  on  it.  To  remove  the  lock,  the  system  must  be  shut  down  and  rebooted 
(which  creates  a  new  file  in  IMachine.Accounting  with  the  date  of  reboot  included  in 
the  file  name).  Thus,  the  only  step  performed  is  b.) 

a.  Disable  the  logging  of  environment  accounting  information. 

(Have  operator  reboot  the  system  at  midnight  at  the  end  of  the  month  to 
close  the  old  accounting  file.) 

b.  Rename  current  accounting  log  file  to  a  file  of  the  form:  mmmddyy.LOG 
where 

mmm  -  previous  month  (e.g.,  Jan) 
dd  -  last  day  of  previous  month  (e.g.,  31) 

yy  -  year  of  the  previous  month  (e.g.,  88) 

<Create  Coinmand> 

" Library . Rename " 

<Coii5)lt> 

Library .Rename (From  =>  "<SELECTION>" , 

To  =>  "»NEW  SIMPLE  NAME«", 

Response  =>  "<PROFILE>") ; 

(Supply  as  value  to  parameter  From; ) 

"  Act  i  vit  y_8  8_0 1_0  9_At_l  1_1 6_1 4  " 

<Next  Item> 

(Supply  as  value  to  parameter  To:) 

"Jan3188_Log" 

<Promot> 

{If  the  system  has  been  rebooted  more  than  once  in  a  time  period,  then 
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multiple  files  for  the  time  period  will  be  generated  and  must  be  concatenated 
to  generate  one  file  for  the  period.} 

c.  Re-enable  the  logging  of  environment  information. 

(Logging  was  enabled  for  the  new  time  period  when  the  system  was 
rebooted  in  step  5.a.} 

6.  Write  a  command  procedure  to  continuously  monitor  the  system’s  performance 
(i.e.,  number  of  processes  currently  active,  CPU  usage  per  process,  physical  mem¬ 
ory  user  per  process,  program  image  running  under  process,  page  faults,  etc.). 

(This  procedure  already  exists  in  the  Rational  Environment.) 

<Create  Coitimand> 

{Coosnand  window  ’  opens ,  and  enter:} 

"What .Jobs" 

<Coinplt> 

What . Jobs (Interval  =>  10, 

User_Jobs_Only  =>  False, 
l^_Jobs_Only  =>  False, 

Running_Jobs_Only  =>  True) ; 

(Use  all  the  default  values.} 

<Proinot> 

(System  monitoring  begins.} 


3.5.  Experiment  #2  Answers 


This  section  has  been  truncated  to  eliminate  those  evaluative  questions  for  which  the  R1000 
lacks  required  capabilities. 

Question  Response 

SM2.1  Describe  the  mechanics  of  creating  a  user  account  group. 

Create  a  command  window  and  enter  the  command: 

Create_Group  (Group  *>  "»GROtJP  NAME«"; 

Response  =>  "<PROFILE>") ; 

Supply  the  desired  group  name  as  the  value  for  the  parameter  Group. 

Execution  of  this  procedure  requires  that  the  executing  job  have  operator 
capability. 

SM2.2  Elapsed  time  for  creating  a  user  account  group? 

Wall  Clock  Time:  2.49  seconds 
CPU  Time:  0.46  seconds 


SM2.3  RIe  size  increase  caused  by  creating  a  user  account  group? 

IMachine.Groups  increased  by  1  byte  after  adding  a  user  account  group. 
SM2.4  Describe  the  mechanics  of  creating  a  user  account. 

Create  a  command  window,  and  enter  the  command: 

Create_User  (User  =>  "»USER  NAME«"; 

Password  => 

Volume  =>  0; 

Response  =>  "<PROFILE>") ; 

Supply  the  desired  user  name  as  the  value  for  the  parameter  User,  and  if  an 
initial  password  is  desired,  enter  it  as  the  value  for  the  parameter  Password. 
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SM2.5 

SM2.6 

SM2.7 

SM2.8 

SM2.9 

SM2.10 

SM2.11 


SM2.12 

SM2.13 

SM2.14 


Execution  of  this  procedure  requires  that  the  executing  job  have  operator 
capabiiity. 

□apsed  time  for  creating  a  new  user  account? 

Wall  Clock  Time:  6.48  seconds 
CPU  Time :  4.24  seconds 

Rie  size  increase  caused  by  creating  a  new  user  account? 

Rie  increase  resuits  from  creation  of  an  entry  in  the  world  IMachine. Users 
and  creation  of  a  home  world  for  the  user.  Rie  size  increased  by  7473  bytes. 
There  was  no  direct  correlation  with  the  length  of  the  user  name  or  password. 

How  easy/difficuit  Is  It  to  create  a  new  user  account? 

Creating  a  new  user  account  is  straightforward  since  only  one  procedure, 
!Commands.Operator.Create_User  is  called  from  a  Rational  command  win¬ 
dow. 

Describe  (in  detail)  the  user  account  information  maintained. 

User  account  name,  user  password,  and  user  account  group  membership. 

What  are  the  resource  requirements  of  an  environment  user? 

Since  the  Rational  Environment  is  not  layered  on  top  of  a  traditional  operating 
system,  this  question  is  not  applicable. 

What  privileges  are  necessary  for  an  environment  user? 

There  are  no  additional  privileges  required  by  the  user,  other  than  access  to 
his  home  world  (i.e.,  the  account  login  is  not  disabled). 

Describe  mechanics  of  adding  a  user  account  to  a  user  group. 

Create  a  command  window  and  enter  the  command: 

Add_To_Group  (User  =>  "»USER  NAME«"; 

Group  »>  "»GROUP  NAME«" ; 

Response  *=>  ”<PROriLE>”)  ; 

Supply  the  desired  user  name  as  the  value  for  the  parameter  User,  and 
supply  the  desired  group  name  as  the  value  for  parameter  Group. 

Identities  are  established  at  login.  Adding  a  user  to  a  group  will  not  be  effec¬ 
tive  until  the  user's  next  login.  The  user  must  log  out  and  then  log  in  again 
for  the  new  group  membership  to  be  added  to  the  user’s  identity. 

Execution  of  this  procedure  requires  that  the  executing  job  have  operator 
capability. 

Bapsed  time  for  adding  a  user  account  to  a  user  group? 

Wall  Clock  Tima:  0.07  seconds 
CPU  Time  :  0.05  seconds 

Rie  size  increase  caused  by  adding  a  user  account  to  a  user  group? 

!Machine.Groups.Env_User  increases  by  1  byte. 

IMachine.Groups.LfseriA/ame  increases  by  1  byte.  Any  other  storage  costs 
could  not  be  measured. 

How  easy/d  Iff  I  cult  is  it  to  add  a  user  account  to  a  user  group? 

It  is  very  easy  to  add  a  user  account  to  a  user  group.  It  only  requires  one 
command,  and  standard  environment  techniques  (such  as  window  creation 
and  command  completion)  facilitate  entering  the  command. 
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SM2.15 

SM2.16 

SM2.19 


SM2.20 

SM2.21 

SM2.22 

SM2.23 


SM2.24 

SM2.25 

SM2.26 


Describe  the  mechanics  copying  old  account  characteristics  into  a  new 
account 

The  Rational  Environment  does  not  support  copying  of  old  account  character¬ 
istics  into  a  new  account.  However,  a  program  can  be  developed  using  the 
Operator  commands  to  create  an  account,  give  it  a  password,  and  add  it  to 
certain  user  groups.  See  System  Management  Experiment  #2,  Steps  6  and 
13,  for  an  example  of  the  aeation  and  use  of  a  default  account  creation 
program. 

SM2.18  Accounts  cannot  be  copied. 

Describe  the  mechanics  of  disabling  logins  for  a  user  account. 

Make  sure  that  the  user  is  logged  out  before  disabling  the  user's  account. 
Create  a  command  window  and  enter  the  command: 

Delete_User  (User  =>  "»USER  NAME«’'; 

Response  =>  ”<PROriI*E>" )  ; 

Supply  the  desired  user  name  as  the  value  for  the  parameter  User. 

Execution  of  this  procedure  requires  that  the  executing  job  have  operator 
capability. 

Bapsed  time  for  disabling  logins  for  a  user  account? 

Wall  Clock  Time:  1.77  seconds 
CPU  Time  :  0.89  seconds 

File  size  increase  caused  by  disabling  logins  for  a  user  account. 

There  is  no  change  in  file  size  when  logins  to  a  user  account  are  disabled. 

How  easy/difficult  is  it  to  disable  logins  for  a  user  account? 

It  is  very  easy  to  disable  logins  to  a  user  account.  It  only  requires  one  com¬ 
mand,  and  standard  environment  techniques  (such  as  window  creation,  com¬ 
mand  completion)  facilitate  entering  the  command. 

Describe  mechanics  of  displaying  user  account  characteristics. 

The  Rational  Environment  supports  a  limited  number  of  "account 
characteristics”;  see  Question  SM2.8.) 

It  is  not  possible  to  display  a  user's  password.  To  display  the  user  groups  to 
which  a  user  belongs,  create  a  command  window  and  enter  the  command: 

Dlsplay_Group  (Group  =>  "»GROUP  NAMK«"  ; 

Response  =>  "<PROriLE>") ; 

Supply  the  desired  user  name  as  the  value  for  the  parameter  User. 

Bapsed  time  for  displaying  user  account  characteristics? 

To  display  the  user  groups  a  user  belongs  to: 

Wall  Clock  Time :  0.03  seconds 
CPU  Time  :  0.02  seconds 

How  easy/difficult  Is  it  to  display  user  account  characteristics? 

The  only  characteristic  that  can  be  displayed  is  the  user  groups  to  which  a 
user  belongs.  This  is  very  easy  to  display,  requiring  only  one  command. 
Standard  environment  techniques  (such  as  window  creation  and  command 
completion)  facilitate  entering  the  command. 

Describe  the  mechanics  of  modifying  a  user  account’s  characteristics. 
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SM2.27 


SM2.28 


SM2.29 


SM2.30 


SM2.31 


The  password  of  a  user  acc»unt  can  be  changed  by  creating  a  command 
window  and  entering  the  command: 

Change_Pas sword  (User  =>  "»OSER  NAME«"; 

01d_Password  => 

New_Pas sword  => 

Response  =>  "<PROriLE>" ; 

See  SM2.33  for  removing  a  user  from  a  user  group  and  SM2.1 1  for  adding  a 
user  to  a  user  group. 

Elapsed  time  for  modifying  a  user  account’s  characteristics. 

To  change  a  user  password: 

Hall  Clock  Time:  0.03  seconds 
CPU  Time  :  0.02  seconds 

See  SM2.34  for  elapsed  time  of  removing  a  user  from  a  user  group,  and  see 
SM2.12  for  elapsed  time  of  adding  a  user  to  a  user  group. 

RIe  size  Increase  caused  by  modifying  a  user  account’s 
characteristics? 

There  is  no  change  in  file  size  for  chainging  a  user’s  password. 

See  SM2.35  for  file  size  change  caused  by  removing  a  user  from  a  user 
group.  See  SM2. 1 3  above  for  file  size  change  caused  by  adding  a  user  too  a 
user  group. 

How  easy/difficult  Is  It  to  modify  an  existing  user  account’s 
characteristics? 

It  is  very  easy  to  change  a  user  password.  It  only  requires  one  command 
and  standard  environment  techniques  (such  as  window  creation  and  com¬ 
mand  completion)  facilitate  entering  the  command. 

See  Questions  SM2.14  and  SM2.36  for  ease/difficulty  of  adding  or  deleting  a 
user  from  a  user  group. 

Describe  the  mechanism  for  creating  a  home  directory  for  a  new  user 
account. 

The  Rational  Environment  command  that  creates  accounts  automatically 
creates  a  user  home  directory  with  the  pathname  lUser.user  name.  See 
Question  SM2.4  for  mechanics  of  creating  a  user  account. 

What  Is  the  default  protection  for  a  user's  home  directory  for  a  new  user 
account.  Is  this  default  modifiable?  If  so,  by  whom?  (user  alone,  user 
and  system  administrator)  Is  this  default  protection  reasonable? 

The  Rational  Environment  does  not  set  up  protections  for  a  user’s  home  di¬ 
rectory.  When  a  user  name  is  created,  a  group  name  corresponding  to  that 
user  name  is  created  by  default.  The  user  name  is,  by  default,  a  member  of 
that  group,  as  well  as  a  member  of  group  Public  and  Network_Publlc.  By 
default,  other  users  have  access  to  read,  modify,  and  change  the  state  of 
Ada  objects  in  another  user’s  home  directory  or  subdirectories;  however, 
other  users  do  not  have  the  ability  to  delete  objects  in  another  user’s  home 
directory.  The  read  and  edit  capabilities  are  by  virtue  of  the  users’  belonging 
to  the  Public  group.  This  default  can  be  modified  by  removing  a  user  from 
the  Public  and  Network_Publlc  groups.  The  user  can  remove  his  user 
name  from  groups.  Addition  to  a  group  requires  operator  capability.  The 
default  protection,  which  allows  a  user  to  modify  objects  in  another  user’s 
directory,  does  not  seem  reasonable. 


CMU/SEI-88-TR-21 


63 


SM2.32 

SM2.33 


SM2.34 

SM2.35 

SM2.36 

SM2.37 

SM2.38 

SM2.39 

SM2.40 

SM2.41 


What  mechanism,  if  any,  Is  employed  to  restrict  access  to  the  environ¬ 
ment  software?  How  can  a  user  gain  access  to  environment  software. 

The  Rational  Environment  software  is  provided  as  executable  code  on  the 
system  only,  so  access  to  modify  or  view  is  not  available. 

Describe  the  mechanics  of  removing  a  user  account  to  a  user  group. 

Create  a  command  window  and  enter  the  command: 

Reinove_From_Group  (User  =>  "»USER  NAME«"; 

Group  =>  "»GROUP  NAME«"; 

Response  *>  ''<PROFILE>")  ; 

Supply  the  desired  user  name  as  the  value  for  the  parameter  User.  Supply 
the  desired  group  name  for  the  value  of  the  parameter  Group. 

Execution  of  this  procedure  requires  that  the  executing  job  have  operator 
capability. 

Elapsed  time  for  removing  a  user  account  to  a  user  group? 

Hall  Clock  Time :  0.11  seconds 
CPU  Time  :  0.04  seconds 

File  size  decrease  caused  by  removing  a  user  account  to  a  user  group? 
There  is  a  1  -byte  decrease  in  file  size. 

How  easy/difficuit  Is  It  to  remove  a  user  account  from  an  account 
group? 

It  is  very  easy  to  remove  a  user  account  from  an  account  group.  It  only 
requires  one  command,  and  standard  environment  techniques  (such  as  win¬ 
dow  creation  and  command  completion)  facilitate  entering  the  command. 

Describe  the  mechanics  of  deleting  a  user  account? 

The  procedure  !Commands.Operator.Delete_User  is  called  from  a  command 
window  and  disables  login  to  a  user  account,  but  preserves  the  user's  home 
world.  The  procedure  Library.Destroy  removes  the  user’s  home  world. 

Elapsed  time  for  deleting  a  user  account? 

See  Question  SM2.20  for  elapsed  time  to  disable  logins  for  a  user  account. 

The  elapsed  time  to  execute  the  Library.Destroy  command: 

Wall  Clock  Time ;  1.10  seconds 
CPU  Time:  0.49  seconds 

RIe  size  decrease  caused  by  deleting  a  user  account? 

No  file  size  decrease  was  seen  when  disabling  logins,  and  a  7556-byte 
decrease  was  seen  when  the  user's  home  world  was  removed. 

How  easy/difficuit  is  It  to  delete  a  user  account? 

Deleting  a  user  account  is  straightforward.  It  involves  calling  the 
Operator. Delete_User  procedure  and  Library.Destroy  commands  from  a 
command  window. 

How  easy/difficult  Is  It  to  learn  the  command  syntax  of  the  user  account 
manager  utility? 

The  Rational  Environment  has  no  "user  account  manager"  utility.  Either  a 
user  account  (called  "Operator")  with  operator  capabiliy  can  be  created,  or 
any  user  can  be  granted  operator  capability.  For  some  commands  to  ex- 
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ecute,  the  executing  job  must  have  operator  capability.  Because  the  syntax 
of  these  commands  is  consistent  with  other  Rational  Environment  com¬ 
mands,  the  system  management  commands  are  easy  to  use. 

Is  the  user  interface  of  the  user  account  manager  utility  consistent  to 
those  of  similar  tools? 

The  system  management  commands  are  very  consistent  with  the  rest  of  the 
Rational  Environment  commands. 

How  useful  are  the  error  diagnostics  of  the  user  account  manager 
utility? 

The  error  diagnostics  are  good,  and  they  are  consistent  with  error  diagnostics 
present  for  other  commands. 

How  well  Is  the  user  account  manager  utility  documented?  is  there  an 
online  help  facility? 

Those  commands  requiring  operator  capability  are  documented  mostly  in  the 
System  Management  Utilities  volume  of  the  Rational  Environment  reference 
manuals.  The  commands  are  well  documented. 

Online  help  is  available  for  commands  in  the  ICommands. Operator  package. 

How  well  Is  the  user  account  manager  utility  integrated  Into  the  under¬ 
lying  operating  environment? 

The  Rational  Environment  is  not  layered  on  top  of  any  operating  environ¬ 
ment:  as  such,  operator  capability  is  a  part  of  the  Rational  Environment. 

Describe  the  operating  system’s  protection  scheme.  Protection 
masks?  Access  control  lists? 

The  Rational  Environment  is  the  operating  system,  and  its  protection  scheme 
is  access  control  lists. 

Describe  the  environment’s  protection  scheme.  Does  the  environment 
offer  any  more  or  less  protection  than  the  underlying  operating  sys¬ 
tem?  if  so,  describe  the  differences. 

See  Question  SM2.46. 

How  and  where  Is  user  account  Information  maintained?  (text  file,  bi¬ 
nary  file) 

User  account  information  is  maintained  as  an  entry  in  the  IMachine. Users 
directory. 

What  kind  of  scheme  is  used  to  protect  account  information? 

A  person  changing  the  user  account  information  must  have  the  operator  ca¬ 
pability. 

Can  passwords  be  displayed  In  humanly  readable  format? 

No. 

What,  If  any,  unique  account  attributes  are  available?  Disallow  chang¬ 
ing  of  an  account’s  password.  Restricted  system  access  based  on  cur¬ 
rent  date  and  time?  System-generated  passwords?  Automatic 
password  expiration  after  a  setable  time  period? 

Accounts  have  passwords,  and  a  user  may  belong  to  certain  user  groups; 
these  are  the  only  account  attributes  available.  There  is  no  way  to  disallow 
the  changing  of  an  account’s  password.  There  is  no  way  to  restrict  system 
access  based  on  current  date  and  time.  There  are  no  system-generated 
passwords.  There  is  no  capability  for  automatic  password  expiration. 
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SM2.52  Is  a  command  procedure  provided  for  creating  new  user  accounts? 

Yes,  the  Ada  procedure  Operator. Create_User  creates  new  user  accounts. 
SM2.53  Is  a  command  procedure  provided  for  removing  user  accounts? 

Yes,  the  Ada  procedure  Operator. Delete_User  deletes  user  accounts. 


3.6.  Experiment  #3  Answers 


Question 

SM3.1 


SM3.2 


SM3.3 


SM3.4 


SM3.5 

SM3.6 

SM3.7 


SM3.8 


Response 

What  Is  the  overall  process  for  updating  the  environment  software? 

Rational  technical  personnel  perform  ell  updates  of  system  software.  The 
form  of  software  update  provided  up  to  this  time  has  been  a  complete  new 
release  of  the  system  software. 

How  frequent  are  new  software  releases? 

Rational  has  marketed  its  system  for  about  three  years  at  the  time  of  this 
evaluation.  During  this  time  there  have  been  four  releases,  the  original  and 
three  updates.  This  may  imply  that  releases  will  occur  a  little  more  frequently 
than  annually,  but  it  is  too  early  to  assume  that  in  the  future  they  will  continue 
to  be  as  frequent. 

Are  new  releases  accompanied  by  release  notes?  Updating 
procedures? 

The  Rational  Environment  Delta  Release  was  accompanied  by  a  complete 
new  set  of  manuals  for  the  Environment.  There  are  online  release  notes  and 
a  message  describing  howto  read  and  print  them  upon  login. 

Are  new  releases  downward  compatible?  Are  new  releases  upwards 
compatible,  or  do  they  supersede  all  previous  releases? 

The  Delta  Release  required  some  software  that  used  some  Rational-specific 
options  to  be  rewritten.  All  Ada  programs  had  to  be  recompiled,  once  the 
Delta  Release  was  installed.  The  degree  of  compatibility  between  releases 
depends  upon  the  features  of  the  new  release  and  is  documented  by  the 
release  notes.  All  new  releases  supercede  previous  releases. 

Can  a  new  release  be  Installed  within  a  multi-user  environment  or  must 
the  machine  be  In  the  single  user  mode? 

SeeSM3.1. 

Can  multiple  versions  of  the  environment  be  running  simultaneously? 
No. 

What  Is  the  procedure  for  fixing  bugs  that  are  uncovered  between 
releases?  (object  code  patches,  new  object  code,  entirely  new  software 
release) 

Bugs  in  the  kernel  of  the  operating  system  are  fixed  with  new  system  soft¬ 
ware  releases.  Changes  can  be  made  to  the  Environment  procedures  that 
appear  in  the  Rational  directory  structure  by  recompiling  the  Ada  units  in¬ 
volved.  If  bugs  are  found  in  this  part  of  the  Environment,  Rational  technicians 
will  make  required  changes  and  recompile  that  part  of  the  system. 

Is  patching  of  executable  Images  supported?  If  so.  Is  It  facilitated  via  a 
command  procedure? 

No.  As  noted  above,  some  parts  of  the  OS  can  be  recompiled. 
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Can  patches  be  applied  within  a  multi-user  environment  or  must  the 
machine  be  In  single-user  mode? 

SeeSM3.1. 

How  easy/d IffI cult  Is  It  to  update  the  environment  software? 

SeeSM3.1. 

How  much  human  Intervention  Is  required  during  the  updating 
procedure? 

SeeSM3.1. 

How  easy  Is  It  to  recover  from  errors  during  the  update  procedure? 

SeeSM3.1. 

How  well  Is  the  update  procedure  documented? 

The  update  procedure  is  documented  only  in  documentation  used  by  Ra¬ 
tional  field  service  technicians. 

Newsletter?  What  Is  the  frequency  of  publication? 

The  Rational  User’s  Group  publishes  a  quarterly  newsletter. 

Interest  and/or  user  groups? 

There  is  a  Rational  User’s  Group  which  meets  quarterly.  It  also  holds  an 
annual  international  meeting. 

Is  there  a  dial-up  computer  number  to  access  a  database  of  previously 
encountered  bugs? 

A  list  of  problem  reports  made  to  Rational  is  available  through  their  Support 
Information  Management  System  (SIMS).  However,  the  primary  purpose  of 
SIMS  Is  to  facilitate  customer  contact  with  Rational  headquarters.  The  list  of 
problems  is  not  particularly  useful  as  a  set  of  bug  reports  because  it  is  unin¬ 
dexed,  and  because  hardware  problems  that  are  not  of  general  interest  are 
included  in  the  problem  database.  See  SM3.20  for  further  information  about 
SIMS. 

Level  of  Software  support?  Levels  are  defined  as  follows: 

Level  1 

7  day,  12-24  hour  phone  service;  maintenance;  revised  versions  of  soft¬ 
ware  and  documentation;  on-sIte  consultation  regarding  problems. 

Level  2 

5  day,  8-12  hour  phone  service;  maintenance;  revised  versions  of  soft¬ 
ware  and  documentation;  remote  consultation  regarding  problems. 

Level  3 

no  phone  service;  no  maintenance;  revised  versions  of  software  and 
documentation;  no  consulting  support;  submit  software  trouble  reports 
formally  In  writing. 

Rational  provides  level  1  phone  service  and  1  consultation.  The 
hardware/software  maintenance  contract  includes  phone  access  to  the  Ra¬ 
tional  24  hour/7  day  Response  Center.  See  SM3.18.  Revised  versions  of 
software  are  installed  as  part  of  regular  maintenance.  Revised  documen¬ 
tation  is  provided  with  revised  software. 

What  Is  the  cost  for  software  maintenance? 
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Software  maintenance  is  bundled  with  Rational’s  overall  customer  support 
fee,  which  is  $4500  per  month  in  January  1988  for  the  Rational  R1000  Model 
200-20.  The  customer  support  fee  has  remained  at  that  cost  since  the  intro¬ 
duction  of  the  Model  200-20  in  November  1986.  This  fee  includes  compre¬ 
hensive  hardware  and  software  onsite  support.  The  hardware  support  in¬ 
cludes  parts  and  on  site  labor.  The  software  support  includes  all  updates, 
upgrades,  and  documentation. 

Is  remote  maintenance  offered  (I.e.,  vendor  dials  Into  system  under 
maintenance  contract  to  service  remotely)? 

A  diagnostic  modem  is  part  of  the  standard  Rational  hardware  configuration. 
If  certain  system  failures  occur  the  Rational  computer  itself  will  call  Rational 
and  request  that  a  customer  representative  be  paged.  The  diagnostic 
modem  will  also  be  used  as  needed  to  diagnose  customer  reported  problems 
as  part  of  the  standard  maintenance  contract. 

What  Is  the  method  of  reporting  software  bugs?  Are  there  any  auto¬ 
mated  tools  available  to  report  errors  (e.g.  a  program  that  makes  It  easy 
to  fill  In  the  form  that  must  be  delivered  to  report  the  error  or  an  elec¬ 
tronic  address  to  mall  the  problem  report?). 

The  standard  Rational  configuration  includes  a  terminal  dedicated  to  contact¬ 
ing  Rational’s  Support  Information  Management  System  (SIMS).  This  termi¬ 
nal  is  used  for  electronic  mail  between  the  user  and  Rational  and  for  logging 
problem  reports.  SIMS  provides  saeen  forms  that  the  user  fills  in  for  sending 
mail  messages  and  entering  problem  reports.  A  bulletin  board  containing 
news  is  available  through  SIMS. 

Average  turnaround  time  from  bug  report  to  bug  fix  to  distribution  of 
patch? 

Turnaround  time  for  fixes  to  the  kernel  is  the  interval  between  system 
releases.  This  was  stated  in  the  answer  to  SM3.2.  Part  of  the  job  of  Rational 
service  representatives  is  to  help  customers  develop  workarounds  to  kernel 
bugs  discovered  in  the  interval  between  system  releases.  Company  policy  is 
to  provide  problem  solutions  rather  than  kernel  patches  so  that  the  software 
in  the  field  will  be  a  known  entity  to  service  representatives  developing  the 
solutions. 

Fixes  to  the  functional  part  of  the  OS  will  be  implemented  as  soon  as  the 
Rational  technicians  find  the  bug.  Patches  are  not  distributed:  rather  the 
section  of  code  containing  the  bug  is  edited  and  recompiled. 

Is  the  software  covered  under  a  warranty?  If  so  for  how  long? 

No. 

What  Is  the  policy  and  procedure  for  acquiring  3rd  party  software  that 
will  execute  within  the  Ada  environment?  Is  there  an  Integration  kit 
available  to  aid  In  Integrating  3rd  party  software  Into  the  environment? 

Since  the  Environment  runs  Ada  exclusively,  only  those  third  party  tools  writ¬ 
ten  in  Ada  can  be  ported  to  the  Environment.  The  Rational  Environment 
supports  ANSI  standard  tape  format  (such  as  is  generated  by  VAX/VMS)  and 
Ethernet  as  a  means  of  importing  programs.  Although  the  Environment  does 
not  store  Ada  source  in  text  format,  TextJO  can  read  Rational  Ada  objects 
as  though  they  were  text.  Thus,  imported  tools  requiring  read  access  to  Ada 
source  in  text  format  will  work  provided  they  use  Text_IO  to  access  text  files. 
Tools  requiring  access  to  system  services  (such  as  the  directory  system)  will 
find  that  sections  of  the  visible  operating  system  interface  (such  as  the  proce¬ 
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dures  that  access  the  directory  structure)  are  undocumented.  Rational  tech¬ 
nicians  will  provide  assistance  to  users  who  are  attempting  to  solve  problems 
that  require  use  of  undocumented  portions  of  the  Environment  system. 

SM3.24  Are  full  disk  backups  supported  for  both  the  software  and  the 

database? 

Yes,  the  full  backup  procedure  takes  a  snapshot  of  the  entire  Environment. 
Rational  recommends  a  weekly  full  backup. 

SM3.25  Are  Incremental  disk  backups  supported  for  both  the  software  and  the 

database? 

Yes;  primary  backup  procedure  records  changes  to  the  Environment  since 
the  last  full  backup  procedure.  Rational  recommends  a  daily  primary  backup. 

SM3.26  Is  there  automated  support  for  restoring  the  software  and/or  database 

element  from  the  backup? 

The  entire  process  of  both  generating  an  Environment  backup  and  restoring 
the  Environment  from  primary  or  full  backup  is  prompted  from  the  operator’s 
console.  The  restoration  operation  restores  the  entire  Environment.  There  is 
no  capability  for  restoring  selected  files  from  a  full  or  primary  backup.  Indi¬ 
vidual  users  can  request  source  archiving  for  selected  files  or  directories. 
Rational  does  not  recommend  backing  up  the  entire  Environment  in  source 
archive  form  because  performing  a  source  archive  of  the  entire  Environment 
would  be  a  very  resource-intensive  and  long-running  process. 


3.7.  Experiment  #4  Answers 

Question  Response 

SM4.1  Describe  the  mechanics  of  enabling  the  logging  of  system  accounting 

Information. 

Logging  of  accounting  information  on  the  Rational  R1000  is  enabled  by  creat¬ 
ing  a  directory  called  IMachIne.AccountIng  when  the  system  is  booted. 
When  the  system  is  booted,  a  file  is  created  that  contains  the  date  and  time 
of  the  reboot.  Disabling  logging  requires  the  intervention  of  a  Rational  techni¬ 
cian  and  involves  changing  the  system  boot  procedures.  The  files  in  this 
directory  contain  records  of  machine  use  between  system  reboots,  with  each 
file  being  given  a  name  containing  the  data  of  reboot.  To  generate  files  that 
contain  accounting  information  for  a  given  time  period,  the  system  must  be 
rebooted  at  the  end  of  each  period.  Within  each  file  a  record  is  generated 
that  logs  usage  data  for  each  user  session,  system-initiated  job,  and  user- 
initiated  background  job  that  terminates  after  the  user  session  that  initiated  it. 

A  session  is  a  user  interaction  with  the  Rational  Environment  from  logon  to 
logoff.  Accounting  information  for  a  session  includes  the  resources  used  by 
all  user-initiated  background  jobs  that  terminate  during  the  session.  Sessions 
have  names  that  appear  in  the  accounting  files.  The  names  represent  sets  of 
session  switches  that  control  Rational  Environment  attributes,  such  as  max¬ 
imum  number  of  windows  on  the  Rational  display.  Users  edit  a  set  of  session 
switches  to  define  a  desired  working  environment.  The  session  names  are 
therefore  not  arbitrarily  chosen,  but  selected  by  the  user  at  logon  from  a  set 
of  already  defined  session  names.  If  the  user  logs  on  with  a  session  name 
that  does  not  exist,  the  Rational  Environment  offers  the  user  the  choice  of 
aborting  the  login  or  creating  the  session  with  its  concomitant  set  of  session 
switches. 
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Elapsed  time  for  enabling  the  logging  of  system  accounting 
Information? 

Enabling  logging  requires  only  the  time  for  directory  creation,  which  is  given 
in  the  Design  and  Development  Experiment. 

Describe  the  mechanics  of  disabling  the  logging  of  system  accounting 
Information. 

The  Rational  Environment  is  designed  to  have  accounting  always  enabled. 
Disabling  logging  requires  intervention  of  a  Rational  technician. 

Elapsed  time  for  disabling  the  logging  of  system  accounting  Informa¬ 
tion? 

See  SM4.3. 

What  are  the  disk  space  requirements  of  the  accounting  log  file? 

Each  entry  in  an  accounting  log  file  is  a  line  of  text  consisting  of  a  fixed  length 
and  a  variable  length  part.  The  first  sixty-one  characters  record  all  infor¬ 
mation  except  the  user  name  and  session  name.  The  variable  length  part 
contains  the  user  name  and  session  name. 

What  Is  the  execution  overhead  associated  with  continuous  collection 
of  accounting  statistics? 

According  to  Rational  designers  at  company  headquarters,  the  overhead  is 
so  low  that  an  attempt  to  measure  it  would  be  masked  by  such  noise  factors 
as  disk  latency.  The  statistics  collection  is  part  of  the  activity  of  the  system 
daemon  and  cannot  be  separated  at  the  programmer  interface  level  from  the 
measurement  of  the  system  daemon  activity. 

What  kind  of  system  accounting  Information  can  be  collected?  CPU 
usage?  Connect  time?  Disk  usage?  Number  of  logins?  I/O  Activity? 
Pages  printed? 

For  each  user  session,  the  following  information  is  logged:  time  and  date 
session  starts  and  ends,  elapsed  time,  CPU  time,  number  of  disk  requests 
and  number  of  jobs  executed  during  the  session.  The  user  session  infor¬ 
mation  about  CPU  time  and  disk  requests  is  a  cumulative  summary  of  the 
usage  information  about  all  the  jobs  initialed  by  the  user  that  terminated  dur¬ 
ing  the  session.  The  same  information  is  logged  for  user-initiated  jobs  that 
extend  beyond  the  end  of  the  session,  as  well  as  for  background  jobs  in¬ 
itialed  by  the  Rational  Environment  itseff. 

Are  callable  program  Interfaces  provided  for  collecting  accounting  sta¬ 
tistics?  If  so,  do  these  Interfaces  support  all  appropriate  services  pro¬ 
vided  by  the  underlying  operating  environment? 

The  callable  interfaces  for  accounting  statistics  provided  by  the  Rational  Envi¬ 
ronment  return  elapsed  CPU  time  and  current  working  set  size  for  a  job. 

What  format  is  employed  for  the  accounting  log  file  (ASCII  text,  com¬ 
pressed  binary)? 

Accounting  information  is  stored  in  ASCII  text  files. 

Describe  the  mechanics  of  dynamically  monitoring  the  system's 
workload. 

The  Rational  Environment  provides  three  procedures  for  monitoring  the  sys¬ 
tem  workload.  One  of  these,  WhatJobs,  continuously  monitors  the  load  and 
updates  a  screen  display  at  a  user-specified  interval.  The  other  two. 
What. Load  and  What. Users,  provide  snapshots  and  terminate  after  gener- 
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ating  one  screen  display.  What.Jobs  is  invoked  by  opening  a  command  win¬ 
dow,  entering  What.Jobs,  and  promoting  the  command  window.  What.  Users 
and  What.Load  are  bound  to  the  keyboard  and  are  invoked  with  a  single 
keystroke. 

SM4.11 


SM4.12 


What. Jobs  lists  for  each  job  the  following: 

•  user  name  (of  user  who  started  job) 

•  session  name 

•  job  number 

•  status  (run,  idle,  wait,  disabled,  queued) 

•  elapsed  time  for  job 

•  total  CPU  time  for  job 

•  percentage  of  CPU  time  consumed  by  job 

•  working  set  size 

•  disk  waits  since  job  inception 

•  job  name 

What.Users  lists  the  following  for  each  job  initiated  by  a  currently  active  user: 

•  user  name 

•  port  number 

•  job  number 

•  status  (run,  idle,  wait,  disabled,  queued) 

•  elapsed  time  for  job,  and 

•  job  name 

What.Load(False)  lists  the  average  number  of  tasks  eligible  for  CPU  time 
over  the  last  100  milliseconds,  the  last  minute,  the  last  5  minutes,  and  the  last 
15  minutes.  When  invoked  with  the  verbose  parameter  set  to  true  (the 
default),  it  displays  the  number  of  tasks  able  to  be  run,  averaged  over  the  last 


What  is  the  execution  overhead  associated  with  dynamically  monitoring 
the  system’s  workload? 

What.Jobs  does  not  show  up  in  the  What.Jobs  window  as  a  separate  job. 
Therefore,  the  overhead  it  creates  must  be  reported  as  part  of  either  general 
system  overhead  or  as  part  of  the  overhead  of  an  idle  user  session  (which  is 
relatively  stable  at  1.75  percent  of  CPU  time).  Where  the  What.Jobs  over¬ 
head  is  reported  cannot  be  determined.  From  the  user’s  point  of  view,  in¬ 
vocation  of  the  What.Jobs  command  simply  causes  the  cursor  to  update  a 
What.Jobs  window  at  a  user-specified  interval  (which  has  a  default  value  of 
ten  seconds).  The  user  can  work  in  other  windows  while  monitoring  the 
system. 

What  type  of  system  workload  monitoring  Is  supported?  Which  of  the 
following  can  be  monitored:  Page  faults,  Swapping,  I/O  activity.  Memory 
Usage,  Process  w  workloads. 

The  information  provided  by  the  three  system  monitoring  procedures  de¬ 
scribed  in  SM4.10  is  listed  separately. 
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SM4.13 

SM4.14 


SM4.15 

SM4.16 

SM4.17 

SM4.18 


100  milliseconds,  1  minute,  5  minutes  and  15  minutes.  It  also  displays  the 
number  of  tasks  waiting  for  pages  from  disk  and  the  number  of  withheld  jobs 
averaged  over  the  four  time  periods. 

Does  a  report  generator  exist  for  summarizing  the  accounting  logs? 

Yes,  a  report  generation  tool  is  available  in  .Tools.System_Availability. 

Describe  the  mechanics  of  reconfiguring  and  rebooting  the  system. 

Reconfiguration  of  the  operating  system  for  performance  involves  two  sepa¬ 
rate  activities,  scheduling  the  clients  of  the  system  daemon  and  setting  the 
parameters  for  the  system  scheduler.  Either  activity  can  be  performed  by 
calling  Environment  procedures  interactively  or  by  incorporating  calls  to  Envi¬ 
ronment  procedures  into  the  initialization  procedure  that  is  run  as  part  of  sys¬ 
tem  booting.  Interactive  invocation  follows  the  standard  Rational  method  of 
executing  a  procedure  from  a  command  window.  Incorporating  procedure 
calls  into  the  system  initialization  procedure  follows  the  standard  Rational 
methods  for  program  editing  and  compilation. 

The  daemon’s  clients  are  procedures  that  perform  housekeeping  functions, 
such  as  disk  garbage  collection,  in  the  Rational  Environment.  Scheduling 
these  clients  is  important  as  several  of  them  consume  so  many  machine 
resources  that  the  system  is  unusable  when  they  are  running,  and  others 
noticeably  slow  the  system.  Rational  estimates  that  the  period  that  the  Ra¬ 
tional  system  will  be  rendered  unusable  by  daemon's  clients  will  range  from 
two  to  six  hours  per  day,  depending  on  the  workload.  The  higher  the  work¬ 
load,  the  more  housekeeping  the  daemon’s  clients  must  perform. 

The  system  scheduler  allows  tailoring  of  system-wide  parameters  for  the  al¬ 
gorithms  that  allocate  CPU  time,  memory,  and  disk  resources  to  the  system 
jobs. 

Additional  system  configuration  capabilities  are  offered  by  the  package  Ter¬ 
minal,  which  allows  setting  communication  port  parameters,  and  by  the  pack¬ 
age  Queue,  which  provides  for  the  management  of  print  queues  (creating 
print  device  lists,  assigning  queues  to  devices,  etc.). 

The  Rational  R1000  has  a  hardware  switch  to  determine  whether  system 
reboot  will  be  manual  or  automatic.  The  manual  reboot  process  is  used  only 
by  Rational  technicians.  When  the  hardware  switch  is  set  to  automatic, 
rebooting  the  system  proceeds  automatically  after  calling  the  system  shut¬ 
down  procedure  or  when  powering  up  the  system.  The  system  can  be  con¬ 
figured  so  that  reboot  is  completely  automatic  or  so  that  the  operator  must 
press  <return>  at  the  system  prompt  "Enter  configuration  to  boot  [Standard]." 

Elapsed  time  of  reconfiguring  and  rebooting  the  system? 

System  rebooting  usually  requires  fifteen  to  twenty  minutes.  When  system 
configuration  procedures  are  called  interactively,  they  execute  within  a  few 
seconds.  The  initialization  procedure  executed  at  system  reboot  can  be  al¬ 
tered  as  fast  as  the  user  can  edit  it. 

How  easy/d  Iff  leu  It  Is  It  to  reconfigure  the  operating  system? 

Executing  the  reconfiguration  procedures  interactively  or  editing  the  initializa¬ 
tion  procedure  is  very  easy. 

How  much  human  intervention  is  required  during  the  reconfigure 
procedure? 

The  reconfiguration  process  is  entirely  manual. 

How  easy  Is  It  to  recover  from  error  during  the  reconfigure  procedure? 
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Out  of  range  values  for  system  reconfiguration  procedure  parameters  will 
generate  constraint  errors.  If  the  procedure  was  invoked  interactively,  the 
user  would  simply  return  to  the  command  window,  edit  the  procedure 
parameters,  and  run  the  procedure  again.  If  the  error  is  generated  during 
execution  of  the  system  initialization  procedure,  the  system  will  complete 
booting,  but  only  one  Rational  terminal  that  is  connected  to  a  port  whose 
communications  parameters  are  hardwired  will  be  enabled.  The  initialization 
procedure  must  then  be  corrected  from  the  hardwired  terminal  and  run  to 
enable  the  remaining  terminals.  This  suggests  that  all  changes  to  the  system 
initialization  procedure  should  be  tested  by  running  the  procedure  when  the 
system  is  up.  Editing  the  initialization  procedure  is  as  easy  as  any  other 
program  development  work  on  the  Rational. 

SM4.19  How  well  Is  the  reconfigure  procedure  documented? 

Complete  documentation  is  provided,  including  guidelines  for  scheduling 
daemon  clients,  an  overview  of  the  system’s  resource-scheduling  algorithms, 
and  detailed  descriptions  of  all  daemon  and  scheduler  procedures  and 
parameters. 

SM4.20  Do  system  resource  (CPU  time,  disk  space,  etc.)  quotas  exist?  if  so,  at 

what  level  can  they  be  set?  (individual  user,  user  account  group,  only 
all  accounts) 

CPU  time  and  working  set  size  quotas  exist.  Disk  usage  is  allocated  by 
withholding  jobs  from  running  when  the  disk  load  becomes  too  high.  The 
parameters  for  the  disk  load  algorithm  can  be  set  by  the  user.  There  is  no 
allocation  of  disk  space.  The  CPU  time  and  disk  usage  allocations  are 
system-wide  only.  Working  set  size  can  be  set  system-wide  and  for  indi¬ 
vidual  jobs. 


3.8.  System  Management  Analysis 

3.8.1.  Functionality 

Users  of  the  R1000  computer  buy  a  package  that  typically  includes  the  R1000  computer,  the 
Rational  Environment,  software  updates,  and  a  Rational  service  contract.  The  service  contract  is 
a  separately  priced  item,  which  includes  software  updates.  The  R1000  and  Rational  Environment 
are  installed  by  Rational  technicians.  Therefore,  users  are  not  involved  in  system  installation. 
System  management  can  supply  only  three  account  characteristics:  the  account  name,  initial 
password,  and  enrollment  in  certain  user  groups.  The  functionality  to  modify  and  display  these 
few  characteristics  is  provided  to  users  with  operator  capability. 

User  work  space  management  attributes  and  operations  can  be  associated  with  an  individual 
account  via  the  Rational  commands,  including  key  bindings,  macro  definitions,  and  session 
switches.  These  are  not  considered  system  management  attributes.  However,  a  procedure 
could  be  created  that  would  provide  a  baseline  of  work  space  management  attributes,  as  well  as 
an  initial  password  and  user  group  membership  upon  user  account  creation. 

Although  the  R1000  does  not  allow  tuning  the  system  by  adjusting  system  resource  quotas  for 
individual  users,  system  management  utilities  do  allow  tuning  by  setting  parameters  for  the  sys¬ 
tem  as  a  whole.  These  utilities  are  not  covered  by  this  experiment. 
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The  system  can  log  sufficient  resource  usage  accounting  information  to  serve  as  a  basis  for  a 
billing  system.  There  is  no  easy  way  to  disable  system  accounting  logging  once  it  is  enabled. 
Comprehensive  accounting  information  is  available  interactively.  There  are  no  documented  pro- 
greim  interfaces  for  obtaining  system  accounting  information  except  for  cumulative  CPU  time  for  a 
job.  Procedures  are  provided  to  control  system-wide  parameters  affecting  system  performance 
both  for  CPU  time,  memory,  and  disk  usage  allocation  and  for  scheduling  of  system  daemon’s 
clients. 

Rational  Environment  installations  and  upgrades  are  done  entirely  by  Rational  technicians  as  part 
of  the  sales  and  maintenance  contracts.  Also,  the  Rational  Response  Center  is  available  by 
phone  to  answer  any  questions.  Throughout  the  performance  of  the  experiments,  the  Response 
Center  was  prompt  in  providing  guidance,  admitting  to  problems,  and  providing  usable 
workarounds. 

3.8.2.  Performance 

Rational  technicians  reserve  a  machine  for  over  a  half  day  to  a  day  to  perform  installation  of  a 
new  release  of  the  Rational  Environment.  Differences  in  installation  time  depend  on  whether  the 
user  has  optional  environment  components  such  as  networking  software  or  cross  compilers. 

The  commands  to  create  a  user  account  group,  create  a  new  user  account,  add  a  user  account  to 
a  user  group,  disable  logins  for  a  user  account,  display  account  charactenstics,  modify  account 
characteristics,  remove  a  user  account  from  a  user  group,  and  delete  a  user  account  are  highly 
interactive.  Most  executed  in  an  elapsed  wall  clock  time  of  about  one  second. 

The  space  required  for  creating  a  new  user  was  7473  bytes.  If  user  access  to  the  account  is 
revoked,  no  space  is  reclaimed  by  the  system,  as  the  user’s  home  world  still  exists.  However,  if 
the  user’s  home  world  is  deleted,  then  the  space  is  reclaimed.  Creating  a  user  account  group 
caused  a  space  consumption  increase  of  1  byte  in  the  IMachine.Groups  directory.  Adding  a  user 
to  the  user  account  group  caused  a  space  consumption  increase  of  2  bytes.  Any  other  storage 
costs  due  to  these  two  operations  could  not  be  measured.  The  space  used  by  IMachine.Groups 
is  reclaimed  when  a  user  account  is  removed  from  a  user  group. 

The  execution  overhead  of  accounting  logging  and  interactive  resource  usage  display  could  not 
be  determined.  System  reboot  takes  approximately  fifteen  to  twenty  minutes  (and  is  required  to 
close  accounting  log  files).  Interactive  response  to  the  system  reconfiguration  commands  was 
quick. 

3.8.3.  User  Interface 

The  System  Management  Experiments  use  the  Rational  Environment  interface.  This  interface 
supports  command  recall,  wildcards,  command  editing,  command  abbreviations,  and  parameter 
prompting.  In  the  Rational  Environment,  the  user  is  always  in  the  Rational  editor,  whose  com¬ 
mands  for  cursor  movement,  object  selection,  and  deletion  operate  on  directories,  command 
windows,  text,  and  Ada  objects.  All  commands  in  the  Rational  Environment  are  Ada  sub¬ 
programs.  They  may  be  invoked  from  within  the  editor  by  selecting  the  command  in  its  home 
directory  and  pressing  the  <Promot>  key,  by  entering  the  subprogram  name  in  a  command  win- 
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dow  (which  provides  a  block  within  which  subprograms  be  run),  or  by  binding  the  subprogram  to 
a  key  on  the  Rational  Terminal  keyboard  at  logon.  Procedures  may  be  bound  to  the  keyboard  so 
that  they  execute  immediately  or  so  that  they  prompt  for  parameters.  A  Prompt_For  key  over¬ 
rides  a  key  binding  for  immediate  execution  and  causes  the  command  bound  to  a  key  to  appear 
in  a  command  window.  A  <Complt>  key  will  generate  a  parameter  list  for  a  command  whose 
name  has  been  entered  in  a  command  window  and  will  also  complete  the  spelling  of  a  procedure 
name  if  enough  of  the  name  is  provided  so  that  it  is  unambiguous.  Many  parameterless  com¬ 
mands  act  on  objects  in  the  Environment,  such  as  directory  entries  or  sections  of  text  or  Ada 
objects  that  have  been  selected  with  the  editor  object  selection  commands. 

The  simple  user  account  management  activities  provided  by  the  Rational  Environment  can  easily 
be  performed  directly  from  a  command  window  in  any  directory  that  has  established  a  link  with 
the  operator  package.  The  only  requirement  of  a  user  of  most  of  the  operator  package  com¬ 
mands  is  that  the  user’s  account  have  operator  capability. 

3.8.4.  System  Interface 

The  commands  for  user  account  management  are  in  complete  accordance  with  the  standard 
Rational  interface.  The  user  account  management  commands  are  Ada  procedures  which  are 
invoked  from  a  command  window. 

The  Rational  Environment  lacks  the  ability  to  disable  machine  usage  accounting  without  the  inter¬ 
vention  of  a  Rational  technician.  According  to  Rational  designers,  the  system  overhead  for  log¬ 
ging  accounting  information  is  so  low  that  an  attempt  to  measure  it  would  disappear  into  the  noise 
generated  by  such  factors  as  disk  latency.  Closing  the  current  logging  file  requires  rebooting  the 
system,  which  is  a  clumsy  arrangement.  Its  contents  may  be  copied  to  another  file  using  the 
Common.Write_File  procedure.  Operating  system  reconfiguration  is  performed  completely  in  ac¬ 
cordance  with  the  standard  Rational  interface,  which  makes  the  reconfiguration  process  easy. 

One  problem  concerning  system  interface  was  encountered  across  several  of  the  experiments. 
Since  this  section  deals  with  the  duties  of  a  system  administrator,  it  will  be  noted  here.  A  random, 
sporadic  generation  of  input  from  an  unused  I/O  port  wasted  50  to  80  percent  usage  of  the  CPU. 
Until  this  hardware  problem  was  corrected,  it  caused  a  degradation  in  system  response  to  many 
of  the  commonly  used  \window  commands.  Due  to  window  manipulation  commands  often  being 
only  one  or  two  keystrokes,  system  interface  degradation  was  immediately  noticeable  and  very 
frustrating.  It  would  be  the  duty  of  the  system  administrator  to  recognize  the  problem  and  correct 
it.  With  the  help  of  a  Rational  Service  Representative  the  bad  I/O  port  was  found,  and  once 
corrected  the  system  response  improved  dramatically. 
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4.  Design  and  Development  Experiment 


4.1.  Introduction 

The  Design  and  Development  Experiment  exercises  the  Environment  support  of  detailed  design, 
code  development,  and  translation.  The  Experiment  consists  of  creating  a  program  library  and 
using  the  Environment’s  editor  to  enter  code  seeded  with  errors.  The  Environment’s  capability  to 
detect  the  errors  is  exercised.  A  second  program  library,  which  will  contain  dependencies  on  the 
first,  is  created:  changes  to  the  first  are  outlined,  and  required  retranslation  effort  is  observed. 

The  Rational  Environment  keeps  the  bodies  of  procedures  declared  as  separate  in  the  Ada  object 
in  which  their  specification  was  declared,  rather  than  in  separate  files.  Aside  from  this,  they  are 
treated  independently  of  their  parent  unit.  Once  the  bodies  of  subunits  have  been  compiled,  they 
appear  in  directories  and  can  be  visited  independently  of  their  parent  unit  and  can  also  be 
promoted  and  demoted  independently  of  their  parent  unit,  provided  that  the  state  of  the  subunit 
body  is  not  higher  than  the  state  of  its  parent  unit. 

The  incorporation  of  subunit  bodies  in  the  Ada  unit  on  which  they  depend  requires  that  the 
Get_Row  and  Get_Col  procedure  bodies  be  created  within  the  body  of  Matrix  Management.  To 
conform  as  closely  as  possible  to  the  existing  script,  the  bodies  of  Get_Row  and  Get_Col  are 
entered  into  Matrix_Management  in  step  7  and  coded  in  step  8. 

The  installed  Ada  objects  in  a  library  contain  much  of  the  semantic  information  in  a  library.  The 
division  of  library  information  between  Ada  objects  and  their  enclosing  context  cannot  be  deter¬ 
mined.  Consequently,  when  the  RationaJ  Environment  measures  disk  usage,  it  combines  the 
changes  in  size  of  the  Ada  object  and  the  changes  in  size  of  the  enclosing  context  into  one  figure 
rather  than  separating  the  figures  into  library  disk  utilization  and  procedure  disk  utilization. 

The  Rational  Environment  requires  that  any  compilation  unit  that  depends  upon  another  compi¬ 
lation  unit  which  is  being  edited  also  be  demoted  to  source  state.  Compilation  units  in  the  source 
state  are  not  visible  to  other  compilation  units.  Obsolete  units  are  never  visible  to  other  units  in 
libraries.  For  this  instantiation  of  the  Design  and  Development  Experiment,  determining  the 
recompilation  status  of  a  library  will  be  interpreted  as  meaning  generating  a  listing  of  the  state  of 
the  Ada  objects  (source,  installed,  or  coded)  in  a  directory  or  world  rather  than  determining  which 
units  in  a  library  are  obsolete. 

In  the  following  experiment  instantiation,  experiment  steps  are  numbered  and  substeps  are  let¬ 
tered.  Sections  of  substeps  are  numbered  with  lowercase  Roman  numerals.  Any  comments 
concerning  the  experiment  step  in  the  context  of  the  Rational  Environment  are  in  regular  type  with 
braces  ({ }).  The  instantiation  of  the  experiment  is  provided  as  a  transcript  of  actual  keystrokes. 
Comments  as  to  the  correct  context  in  which  to  type  the  indicated  keys,  and  comments  as  to  what 
the  keystroke  will  accomplish  are  indented,  enclosed  in  braces  ({  })  and  printed  in  a  different 
typeface  typeface.  The  required  keystrokes  are  indented  and  printed  in  typeface  typeface, 
and  are  indicated  either  by  the  letter(s)  on  the  key  or  by  its  keymap  designation  in  angle  brackets 
(<  >)• 
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4.2.  Experiment 

1 .  Set  up  experiment 

a.  Create  directory  named  EXP_LIB,  in  which  the  experiment  will  be  per¬ 
formed. 

<Create  Direct ory> 

{A  coxnmand  window  opens, 
supply  Exp^Llb  as  value 
of  parameter  Naxoe .  } 

(Name  => 

"EXP_LIB" 

<Promot> 

b.  Create  a  subdirectory  under  the  experimental  directory,  named  ADA_LIB,  to 
house  Ada  source  code  fragments  that  will  be  required  throughout  the  ex¬ 
periment. 

{Move  cursor  to  Exp^Llb.} 

<De£inltion> 

<Create  World> 

(A  command  window  opens; 
supply  Ada  Lib  as  value 
of  parameter  Name .  } 

(Name  =>  ””) 

”Ada_LIB” 

<Promot> 

<Create  World> 

{ S upp ly  Ada__Lib__Spe  c_E r r or s 
as  value  of  parameter  Name . } 

(Name  *>  "”) 

"Ada_LIB_SPEC__ERRORS  " 

<Promot> 

<Create  World> 

{ Supp ly  Ada^Lib_Body_E r r or  s 
as  value  of  parameter  Name . } 

(Name  =>  ”") 

"  Ada_LIB_BODY_ERRORS  " 

<Proinot> 

c.  Create,  as  text,  the  source  code  fragments  and  data  files  in  ADA  _LIB. 
Appendix  5.A  exhibits  these  files  by  filename. 

{Objects  to  be  entered  are  shown  below  sorted  by  library  with  the  step  in 
which  the  object  is  used  indicated.  Also  shown  is  the  appendix  section  and 
exhibit  number  from  Evaluation  of  Ada  Environments,  Chapter  5.  Multiple 
libraries  are  used  because  the  Rational  directories  function  as  program 
libraries  and  allow  only  one  compilation  unit  of  a  given  name  and  type  in  a 
directory.} 


Step 

Appendix 

Exhibit 

In  Ada_Ub_Spec_Errors: 
Matrix  Management  spec 

3c 

5.1 

1.2a 

In  Ada_Ub_Body_Errors: 

Vec  Main 

6b 

5. A. 7 

1.4a 
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MatrixJManagexnent  body 

7a 

5.B.3 

— 

In  Ada_Ub: 

Vector  Management  Body 

7b 

5.B.18 

- 

Matrix  Main 

8a 

5.B.5 

- 

{Note:  Vector_Management  Spec  (Appendix  5.1,  Exhibit  1.1a)  will  be  en¬ 
tered  by  hand,  rather  than  copied  from  a  library  in  step  3bi.  Errors  shown  in 
Vector_Management  spec  cannot  be  committed  to  disk,  because  commit¬ 
ting  the  file  causes  syntactic  completion.} 

d.  Develop  a  command  named  recordit  to  collect  general  experimental  data. 

(For  this  sCTipt  the  library  creation,  the  file  copy  command  Ubrary.Copy  and 
Ada  object  promotion  commands  have  been  incorporated  into  procedures 
that  instrument  them  by  measuring  time  and  disk  space  utilization.  These 
instrumented  procedures  are  then  bound  to  the  Rational  keyboard.  The 
code  for  these  procedures  is  listed  in  Appendix  B.} 

e.  Develop  a  command  named  time  to  collect  experimental  timing  data. 

(See  l.d.} 

2.  Identify  objects  and  operations. 

The  R1 000  provides  no  support  for  graphical  design  methods. 

3.  Create  package  specification(s). 

a.  Create  program  library  named  PROJECT_LIB.  Measure  the  time  it  takes  to 
create  program  library.  Measure  disk  utilization  for  newly  created  program 
library. 

<Create  Directory> 

{A  coaomand.  window  opens; 
supply  Project_Lib  as  the 
value  for  Directory_Naiiie . } 

(Directory_Nasve  =>  "  " ) 

"Project_Lib" 

<Proinot> 

b.  Create  package  specification  for  a  package  named 
VECTOR_MANAGEMENT. 

i.  Enter  the  package  specification,  which  is  seeded  with  errors  exactly 
as  it  is  shown  in  Exhibit  1.1a. 
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{Move  cursor  over  PROJECT_LIB  in 
the  EXP_^LIB  directory.  } 

<De  finit ion> 

(Write  a  message  to  the  system  message 
window  (which  shows  the  compiler  error 
messages)  to  label  the  error  messages 
that  will  be  generated  by  attempting  to 
compile  the  specification  of 
Vector_Management .  } 

<Create  Command> 

(A  command  window  opens;  enter:} 

"message . send" 

<CQmplt> 

(Enter  user  id  as  value  for  parameter 
Who.  } 

<Next  Item> 

(Enter  specification  name  as  value 
for  parameter  Message.} 

"  vect  or_management_spec " 

<Promot> 

(Message  appears  in  system  message  window, 
open  window  for  anonymous  Ada  object 
creation. } 

<Object>  I 

(Enter  source  into  the  Ada  object 
as  shown,  in  Evaluation  of  Ada 
Environments,  Chapter  5,  Section  5.A.1 
Exhibit  1.1a.} 

ii.  Display  and  correct  translation  errors. 

<rormat> 

(Correct  errors  shown  by  format 
Icey.} 

{Note  that  the  format  key  adds  the  missing  "is"  and  "of"  and  adds  the 
prompt  "[expression]"  for  the  missing  "FLOAT."} 

iii.  Transiate  into  program  library  PROJECT_LIB.  Measure  elapsed 
and  CPU  times  for  translation. 

(Compile  to  installed  state.} 

<Promot> 

(Compile  to  coded  state.} 

<Promot> 

iv.  Compare  corrected  package  specification  to  Exhibit  1.1b.  (Note  that 
the  file  resides  in  Ada_LIB.  Correct  any  differences  and  retranslate  if 
necessary.  Measure  program  library  disk  utilization  attributable  to 
the  package  specification. 

(Package  specification  is  as  shown  in  Evaluation  of  Ada 
Environments,  Chapter  5,  Section  5.A.2  Exhibit  1.1b.} 

c.  Create  package  specification  for  a  package  named 
MATRIX^MANAGEMENT. 

i.  Enter  in  the  package  specification,  which  is  seeded  with  errors,  ex¬ 
actly  as  it  is  shown  in  Exhibit  1.2a. 
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{Close  Vector_Manageznent  spec  window 
and  move  cursor  back  Into  PROJECT__LIB 
world. } 

<Object>  G 

{Move  cursor  to  Project  Lib  command 
window  and  make  notation  In  system 
message  window  that  any  following 
compiler  errors  refer  to 
Matrlx^Management^Spec .  } 

<Wlndow>  <Down  Arrow> 

{Make  message  command  editable.} 

<Item  Off> 

{Change  Vector_Management  Spec  to 
Matrlx^Management^Spec  and  execute 
message  coxnmand.  } 

<Pronxot> 

{Copy  Matrix  Management  spec  with  errors 
to  Project^Llb  In  command  window  of 
Project_Llb.  } 

Library .  Copy 
<Complt> 

{Supply  pathname  to  Matrix  Management 
spec  and  Matrix  Management  as  value 
for  From  parameter . } 

"  ^Ada^Llb_Spec_Errors  .Matrlx_Management " 
<Promot> 

{Move  cursor  to  directory  entry 

for  Matrix  Management  spec  and  select  It . } 

<Object>  <Left  Arrow> 

{Open  a  window  to  edit  Matrlx_Management 
sp«c. } 

<Edi.t> 

ii.  Display  and  correct  translation  errors. 

{Use  format  key  to  find  syntax  and  local  semantics  errors,  seman- 
ticize  key  to  find  semantic  errors,  next  item  key  to  move  between 
errors,  and  explain  item  key  to  obtain  explanation  of  syntax  and 
semantics  errors.  Note  that  missing  second  <>  for  the  array  defini¬ 
tion  is  inserted  by  pressing  the  format  key.) 

iii.  Translate  into  program  library  PROJECT_LIB.  Measure  elapsed 
and  CPU  times  for  translation. 

{Compile  to  installed  state.} 

<Promot> 

{Compile  to  coded  state.} 

<Promot> 

iv.  Compare  corrected  package  specification  to  Exhibit  1 .2b.  Correct 
any  differences  and  retranslate  if  necessary.  Measure  program 
library  disk  utilization.  Measure  disk  utilization  attributable  to  the 
package  specification. 

{Package  spedfication  is  as  shown  in  Evaluation  of  Ada 
Environments,  Chapter  5,  Section  5.A.4  Exhibit  1 .2b.} 
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4.  Design  subprogram  control  flows,  identify  subprogram  interdependencies,  and  de¬ 
fine  subprogram  specifications  local  to  each  package  body. 

The  Rational  Environment  provides  no  graphical  design  aids. 

5.  Create  package  body  for  VECTOR_MANAGEMENT. 

a.  Generate  package  body  of  VECTOR_MANAGEMENT  using  a  null  body 
generator  if  available.  Otherwise,  use  vector_body_null  in  Ada_LIB. 

{Cursor  will  be  in  spec  of 
Matrix_Management  at  end  of 
step  3 .  Close  Matrix_Manageiiient 
spec  window  and  move  cursor  back 
to  Pro ject_Lib . } 

<Object>  G 

<Window  <Down  Arrow> 

(Retrieve  command  window  with 
message . send,  in  order  to 
note  in  system  message  window 
that  any  following  coo^ilation 
errors  apply  to  the  body  of 
Vector_Management . } 

<Object>  U 

(Change  Matrix_Management_Spec  to 
Vector_Management_Body  and  execute 
message  command. } 

<Promot> 

{Move  cursor  to  Vector_Management ' Spec 
in  the  Project_Lib  directory  window,  and 
select  it . } 

<Object>  <Iieft  Arrow> 

<Create  Body> 

(Note:  A  window  opens  on  skeleton  of 

Vector_Management ' Body . } 

{From  this  point  on,  assume  that  a  message  indicating  what  unit  is  being 
compiled  will  be  sent  to  the  message  window  before  every  compilation  of  a 
unit  containing  errors.} 

b.  Modify  the  pairwise  vector  multiplication  function. 

i.  Enter  the  function  body,  which  is  seeded  with  errors,  exactly  as  it  is 
shown  in  Exhibit  1 .3a. 

{The  missing  "is"  in  line  2  of  the  code  in  Evaluation  of  Ada 
Environments,  Chapter  5,  Section  5.A.5  Exhibit  1 .3a  is  prevented  by 
use  of  the  null  body  generator.  Enter  remaining  code  as  shown.) 

ii.  Display  and  correct  translation  errors. 

{Use  format  key  to  find  syntax  and  local  semantics  errors,  seman- 
ticize  key  to  find  semantic  errors,  next  item  key  to  move  between 
errors,  and  explain  item  key  to  obtain  explanation  of  syntax  and 
semantics  errors.) 

iii.  Translate  into  program  library  PROJECT_LIB. 
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{Conyile  to  installed  state.} 

<Promot> 

{Con^ile  to  coded  state.} 

<Proinot> 

iv.  Compare  corrected  package  body  to  Exhibit  1 .3b.  Correct  any  dif¬ 
ferences  and  retranslate  if  necessary.  Measure  program  library  disk 
utilization.  Measure  disk  utilization  attributable  to  the  package  body. 

{Package  specification  is  as  shown  in  Evaluation  of  Ada 
Environments,  Chapter  5,  Section  5.A.6  Exhibit  1 .3b.} 

6.  Create  a  main  program  named  VEC_MAIN  in  a  separate  program  library  to  drive 
pairwise  vector  multiplication. 

a.  Create  a  program  library  named  TEST_LIB  from  within  the  directory 
PROJECT_L!B  that  will  contain  compilation  units  that  have  dependencies 
upon  units  in  PROJECT_LIB. 

{Cursor  is  in  body  of  Vector  Management 
at  end  of  step  5;  close  Vector  Management ' Body 
window  and  move  cursor  to  Project_Lib  window. } 
<Object>  C 
<Create  Directory> 

{Note  that  a  unit  compiled  in  a 
directory  within  a  world  has  as  a 
context  all  other  units  that  have  been 
compiled  in  the  world  or  in  a  directory 
within  the  world.  Supply  Test  Lib  as 
the  value  for  parameter  Name . } 

(Name  => 

”Test_Lib” 

<Promot> 

b.  Create  a  test  main  program  named  VEC_MAIN  that  will  be  translated  into 
TEST_LIB. 

I.  Create  the  procedure  VEC_MAIN,  which  is  seeded  with  errors,  by 
copying  it  from  Ada_LIB.  Refer  to  Evaluation  of  Ada  Environments, 
Chapter  5,  Section  5.A.7,  Exhibit  1 .4a. 
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<Open  Test  Lib  window  by  moving  the 
cursor  over  Test_Lib  in  Project_Lib 
directory. } 

<De£inition> 

{Copy  Vec  Main  with  errors  into 
Test_Lib. } 

<Create  Coinmand> 

Library . Copy 
<Coinplt> 

{Supply  pathname  to  Vec  Main  and 
Vec^Main  as  value  for  parameter 
From.  } 

(From  =>  "”...) 

”'^'"Ada_Lib_Body_Errors  .  Vec_Main" 

<Promot> 

{Move  cursor  over  Vec_Main 
directory  entry  and  select  it . } 

<Object>  <Left  Arrow> 

{Open  a  window  containing  Vec_Main 
to  edit . } 

<Edit> 

ii.  Display  and  correct  translation  errors.  Display  a  cross-reference 
map. 

{Use  format  key  to  find  syntax  and  local  semantics  errors,  seman- 
ticize  key  to  find  semantic  errors,  next  item  key  to  move  between 
errors,  and  explain  item  key  to  obtain  explanation  of  syntax  and 
semantics  errors.} 

{The  Rational  cross  reference  utility  requires  that  objects  be  in  the 
installed  state  or,  if  in  the  source  state,  that  they  have  been  success¬ 
fully  semantidzed  immediately  prior  to  use  of  the  cross  reference 
utility.  Therefore,  Vec_Main  must  be  successfully  semantidzed  be¬ 
fore  the  Xref  calls  are  made.} 
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{Move  cursor  to  Test^Lib  window. } 

<E  nc 1 o  s lng> 

<Create  Command^ 

(Command  window  opens  showing 
previous  command;  enter: } 

"Xref  .Uses*' 

<Con^lt> 

(List_Of_Naines  =>  "<IMAGE>", 

Visible  Declarations_Only 

=>  True,  . . - ) 

(Supply  Vec_Main  as  the  value  for 
parameter  List_0£_Names  .  } 

"Vec_Main'* 

(Go  through  a  list  of  Boolean  switches 
turning  on  the  switches  for  information 
that  is  not  needed  in  the  Xref 
listing. } 

Numeric  7  <Next^Item> 

"true"  (report  use  of  constants} 

Numeric  3  <Next  Item> 

"true"  (report  use  of  labels} 

<Next  Item> 

"true"  (report  use  of  packages} 

Nxmeric  5  <Next  Item> 

"true"  (report  use  of  variad>les} 

Nxmeric  3  <Next  Item> 

(Save  the  Xref  results.} 

" Vec_Main_Xref " 

<Promot> 

iii.  Translate  into  program  library  TEST_LIB. 

(Move  cursor  to  window  containing  Vec^Main 
and  con^ile  it  to  installed  state . } 

<Promot> 

(Con^ile  to  coded  state.} 

<Promot> 

iv.  Compare  corrected  package  specification  to  Exhibit  1 .4b.  Correct 
any  differences  and  retranslate  if  necessary.  Measure  program 
library  disk  utilization.  Measure  disk  utilization  attributable  to  the 
procedure. 

(Package  specification  is  as  shown  in  Evaluation  of  Ada 
Environments,  Chapter  5,  Section  5.A.8  Exhibit  1.4b.} 

c.  Create  executable  module.  Execute.  Halt  execution.  Resume  execution. 
Time  module  creation.  Observe  execution  error  message(s). 

(Rational  links  object  code  contained  in  Ada  objects  into  an  executable 
module  either  at  runtime  or,  if  the  pragma  Main  is  used  in  the  main  program, 
at  compilation  time.  Creation  of  an  executable  module  is  therefore  not  an 
observable,  measurable  step.} 
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{Move  cursor  to  Test_Lib  window.} 

<Enclosing> 

{Move  cursor  over  Vec^Main  and 
select  it . } 

<Object>  <Left  Arrow> 

{Execute  Vec_Main. } 

<Proniot> 

{Move  job  to  background  mode.} 

<Control>  G 

{Halt  execution  of  job.} 

<Job  Disable> 

{Resume  execution  of  job.} 

<Job  Enable> 

{Note  the  job  enable  and  job  disable  keys  stop  all  jobs.  These  keys  can 
prompt  for  a  job  number  so  that  a  specific  job  is  disabled,  but  Vec_Main 
does  not  run  long  enough  to  go  through  the  mechanics  of  disabling  a  single 
job.  If  Vec^Main  were  run  under  the  debugger,  stopping  and  starting  it 
would  be  easy.  Running  under  the  debugger  does  not  require  recompila¬ 
tion,  just  use  of  the  meta  key  in  combination  with  the  promote  key  (<Meta> 
<Promot>).} 

d.  Determine  the  cause  of  the  execution  error  by  first  browsing  VEC_MA1N 
and  noticing  that  the  variable  v3  is  of  TYPE  VECTOR(1..4).  Examine  the 
statement  invoking  painArise  vector  multiplication:  products  :=  v3*u3.  Then 
browse  the  pairwise  vector  multiplication  function  and  notice  that  there  is  no 
check  for  compatible  dimensions. 

{Move  cursor  to  Vec  Main' Body 
In  Test  Lib  directory  window. } 

<Definition> 

{Move  to  Test^Lib  window.} 

<Enclosing  Object> 

{Move  to  Project_Lib  window,  } 

<Enclosing  Object> 

{Move  ctirsor  over  Vector_Management 
body. } 

<Definition> 

7.  Create  package  body  for  MATR1X_MANAGEMENT. 

a.  Create  package  body  for  MATR1X_MANAGEMENT  by  copying  existing  ver¬ 
sion  from  matrix_body_errors  in  Ada_LIB.  Correct  all  errors  except  for  the 
exception  declaration,  which  will  be  corrected  in  the  next  step. 
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{Cursor  is  in  window  containing 

Vector^Management  body  after 

step  6;  move  to  Project^^Lib  window.} 

<Enclosing  Object> 

(Turn  off  selection  of  Vector^Management . } 

<Item  Off> 

<Create  Comma nd> 

{Cursor  moves  to  command  window  containing 
last  command  issued  with  this  window;  change 
command  to : } 

”  Library .  Copy  ’’ 

<Complt> 

(From  =>  ”<REGION>”  . . . ) ; 

{Supply  parameter  value  for  parameter 
From.  ) 

”  '^Ada_^Lib_^Body_^Errors  .Matrix^Management " 

<Promot> 

{Move  cursor  to  Matrix  Management  body 
in  Project^Lib  directory  and  select  it.) 

<Object>  <Left  Arrow> 

{Open  window  to  edit  Matrix^Management  body. } 

<Edit> 

{Use  format  key  to  find  syntax  errors 
and  local  semantics  errors ^  semanticize 
key  to  find  semantic  errors,  next  item 
key  to  move  between  errors,  and 
explain  item  key  to  obtain  explanation 
of  syntax  and  semantics  errors .  Commit 
incorrect  Matrix^Management  body  to  disk.) 

<Enter> 

b.  Substitute  for  the  VECTOR_MANAGEMENT  package  body  a  revised  ver¬ 
sion  copied  from  vector_body_excptn  in  Ada_LIB.  This  version  contains  a 
non-null  INNER_PROD  function  and  a  test  for  incompatible  dimensions  in 
the  pairwise  vector  multiplication  function.  Add  "Dimension_Error  : 
exception;"  to  the  package  specification  and  retranslate. 
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{At  end  of  step  the  cursor  is 
in  Matrix^Mazxagement '  body;  xziove  cursor 
to  Project^Lib  directory, } 

<Enclosing  Object> 

{Turn  off  selection  of  Matrix^Management  body.} 

<Item  Off> 

<Create  Conimand> 

{Cursor  moves  to  command  vrindow;  replace 
previous  command: } 

"Library. Copy” 

<Con^lt> 

(From  =>  "<CXJRSOR>"  .  .  .)  ; 

{Supply  value  for  parameter  From:} 

”  '^Ada__lib .  vector^management '  body" 

<:Promot> 

{Alter  the  spec  of  Vector^Managexnent . } 

{Move  cursor  to  Vector^Management '  Spec 
in  Project^Lib  directory  and  select  it.} 

<Object>  <Left  Arrow> 

{Demote  Vector_Management '  Spec  to 
installed  state . } 

<Install  Unit> 

{Open  window  to  incrementally  edit 
Vector^Management  ’  Spec . } 

<Definition> 

{Move  cursor  into  declarative  region 
of  Spec.  Open  edit  window  with 
cursor  at  the  declaration  prompt . } 

<Object>  I 

{Enter  the  declaration  of  the 
Dixnension^Error  exception  and  format 
to  fit  in  Vector__Managexnent '  Spec .  } 

<Format> 

{Add  declaration  to  rest  of  Spec.} 

<Promot> 

{Return  Spec  to  coded  state.} 

<Promot> 

{Move  cursor  to  Project_Lib  window.} 

<Enclosing  Object> 

{Code  the  new  Vector^Management  body; } 
move  cursor  to  Vector_Manageinent  body 
and  select  it . } 

<Object>  <Left  Arrow> 

{Promote  Vector  Management  body  to  coded 
state . } 

<Code  Unit> 

c.  Create  function  body  for  GET_ROW  and  null  body  for  GET_COL  by  copying 
from  GET_ROW  in  Ada_LIB.  but  do  not  translate  until  so  directed  in  a  sub¬ 
sequent  step.  Retranslate  MATRIX_MANAGEMENT  package  body  into 
PROJECT_LIB. 

{The  Rational  Environment  requires  that  separate  unit  bodies  be  part  of  the 
Ada  object  in  which  their  specifications  are  declared.  This  can  be  achieved 


88 


CMU/SEI-88-TR-21 


in  at  least  two  other  ways  besides  the  method  shown  in  the  script;  the  pro¬ 
cedures  can  be  compiled  independently  and  copied  into  the 
Matrix_Management  Ada  Object  by  using  the  Library.Copy  procedure,  or 
they  can  be  copied  from  their  own  window  to  the  Matrix  Management  win¬ 
dow  with  the  "<Object>  C"  key  combination.  In  either  case,  the  separate 
declaration  in  Matrix_Management  is  automatically  generated  as  is  the  sep¬ 
arate  body  syntax.) 

{Move  cursor  to  Matrlx^Management 
body  in  Project_Lib  directory.} 

<Definition> 

{Move  cursor  to  Get_Row  function 
and  select  it . } 

<Object>  <Left  Arrow> 

<Edit> 

{Enter  source  as  shown  and  commit 
Get_Row  body  to  disk. } 

<Enter> 

{Return  to  Matrix_Management  body.  } 

<Object>  G 
{ Select  Get^Col . } 

<Object>  <Down  Arrow> 

<Edit> 

{Enter  source  as  shown  and  commit 
Get_Col  body  to  disk.} 

<Enter> 

{Return  to  Matrix  Management  body.} 

<Object>  G 

{Compile  Matrix  Management  body. } 

<Code  Unit> 

{Return  to  Project_Lib  directory. } 

<Object>  G 

8.  Create  a  main  procedure  named  MAT_MAIN  to  drive  matrix-vector  multiplication. 

a.  Create  main  procedure  by  copying  Matrix_Main  from  ADA_LIB.  Translate 
main  procedure  into  program  library  TEST_LIB.  List  the  compilation  unit 
names  and  types  in  program  library  TEST_LIB  and  PROJECT_LIB.  List 
package  and  subprogram  interdependendes.  Determine  the  completeness 
and  recompilation  status  of  both  program  libraries. 
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{At  end  of  step  1 ,  the  cursor  Is  In  the 
Project_Lib  directory.  Move  the 
cursor  over  Test  Lib  and  copy 
Mat_Main  from  Ada^Lib .  } 

<Definition> 

<Cr  eat  e__Cotnxnand> 

” Library . Copy ” 

<Complt> 

(From  =>  ”<REGION>”  . . . ) ; 

(Supply  value  for  parameter  From:} 

”'^^Ada_lib  .mat_main'  body" 

<Promot> 

{Move  cursor  to  Mat_Main' Body,  and 
select  it } 

<Object>  <Left  Arrow> 

{Promote  Mat_Main  to  the  coded  state.} 

<Code  Unit> 

{List  compilation  units'  type  and  status 
in  Test^Lib.} 

<Create  Command> 

"Ada^List" 

<Complt> 

"0'c(Ada) " 

<Promot> 

{Generate  Xref  listing  for  Test  Lib.} 

<Create  Coxnmand> 

{Replace  previous  command  in  command  window: } 
"Xref .Uses" 

<Coo:^lt> 

(List_Of_Names  =>  "<IMAGE>"  .  .  . ) 

Numeric  11 
<Next  Item> 

"true" 

<Promot> 

{Move  cursor  to  Project_Lib  directory.} 
<Enclosing  Object> 

{List  compilation  units'  type  and  status 
in  Pro ject_Lib . } 

<Create  Command> 

"Ada_List" 

<Complt> 

"c(Ada) " 

<Promot> 
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{Generate  Xref  listing  for  Pro ject^Llb . } 

<Create  CoxzsQand> 

"Xref .Uses” 

<Coii^lt> 

( [Llst_Of_Names  =>  "<IMAGE>"  ...) 

"0" 

Numeric  11 
<Next  Itein> 

"true " 

<Proinot> 

b.  Create  executable  module.  Execute.  Time  how  long  it  takes  to  create  mod¬ 
ule. 

{Since  the  Rational  Environment  links  at  runtime,  the  only  applicable  part  of 
this  step  is  Execute.} 

{Move  cursor  to  Test^Llb  In  Project_Llb 
directory. } 

<Def lnltlon> 

{Move  cursor  to  Mat_Maln  In  the 
Test  Lib  directory  and  select  It.} 

<Object>  <Left  Arrow> 

<Promot> 

{Note  error  message  that  Get_Row 
and  Get^Col  have  not  been  Installed. 

Move  cursor  to  Project_Llb  directory.) 

<Encloslng  Object> 

{Move  cursor  to  Get  Row  and 
select  It . } 

<Object>  <Left  Arrow> 

<Code  Unlt> 

{Move  cursor  to  Get_Col  and 
select  It . } 

<Object>  <Left  Arrow> 

<Code  Unlt> 

{Move  cursor  to  Test_Llb 
In  Pro ject_Llb  directory. } 

<Def lnltlon> 

{Move  cursor  to  Mat  Main  In  the 
Test_Llb  directory  and  select  It . } 

<Object>  <Left  Arrow> 

<Promot> 

9.  Modify  package  specifications  and  bodies  and  examine  system  retranslation  be¬ 
havior  using  MAT_MAIN  as  a  main  procedure  (Figure  5-6). 

a.  Change  a  package  specification  by  removing  a  function  specification  that  no 
other  package  depends  upon:  Delete  pairwise  vector  multiplication  specifi¬ 
cation  and  store  temporarily  in  a  separate  location  for  subsequent  reuse. 
Translate.  Create  an  executable  module.  Observe  system  retranslation 
behavior. 
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{Cursor  is  in  Test^Lib  after  step  8; 
move  cursor  to  Project_Lib  window. } 

<Enclosing  Object> 

{Create  Temp  Storage  for  function 
to  be  deleted.} 

<Object>  I 

{Return  cursor  to  Project^Lib  window. } 

<Enclosing  Object> 

{Move  cursor  to  Vector  Management '  Spec .  } 

<Definition> 

{Demote  Spec  to  installed  state.) 

<Xnstall  nnit> 

{Move  cursor  to  pairwise  vector 
multiplication  function  spec  and 
select  it . } 

<Object>  <Left  Arrow> 

{Move  cursor  to  window  for 
anonymous  Ada  object  and  copy 
function  declaration.} 

<Region>  C 

{Return  cursor  to  Vector_Management '  Spec 
window . } 

{Select  function  again.} 

<Object>  D 

{Note  a  window  opens  showing  objects  made 
obsolete  by  removal  of  pairwise  multiplication 
(Vec^Main  body  and  Vector_Management  body)  . 

Move  cursor  over  Vec_Main' Body  and  select  it . } 
<Object>  <Left  Arrow> 

{Demote  Vec^Main^ Body  to  source.} 

<Source  Unit> 

{Move  cursor  over  Vector_Management '  Body  and 
select  it . } 

<Object>  <Ireft  Arrow> 

{Demote  Vector^Management ' body  to  source.} 

<Source  Unit> 

{Move  cursor  back  to  Vector_^nagement  ^  Spec 
window  and  again  select  the  function. } 

<Object>  D 

{Compile  Vector  Management ' Spec  to  coded  state.} 
<Promot> 

{Move  cursor  to  Test^Lib  Window  and 
select  Mat^Main' Body . } 

<Object,  Left  Arrow> 

{Note:  A  simple  <Promot>  keystroke  could  be 

used  below,  but  <Code  (All  Worlds) >  generates 
a  log  and  <Promct>  does  not . } 

<Code  (All  Worlds) > 

b.  Change  package  body  by  changing  an  algorithm  in  a  subprogram  body: 
Change  INNER_PROD  body  so  that  it  no  longer  uses  pairwise  vector  multi¬ 
plication.  Translate  into  PROJECT_LIB.  Create  executable  module.  Ob¬ 
serve  system  retranslation  behavior. 
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{Move  cursor  back  to  Project^Lib  window. } 

<Enclosing  Object> 

{Move  cursor  to  Vector^Management  body,  ) 

<Definition> 

{Make  Vector_Manageinent '  Body  editable,} 

<Install  nnit> 

{Move  cursor  to  inner^product  function 
and  select  it . } 

<Object>  <Left  Arrow> 

<Edit> 

{Note:  inner^roduct  body  moves  to  an  edit 
window  and  demoted  to  source ,  Change  inner 
product  and  reinstall  it  into 
Vector  Management ' Body , } 

<Promot> 

{Compile  Vector_Management  body  to  coded, ) 

<Promot> 

{Return  to  Project_Lib  window. ) 

<Enclosing  Object> 

{Move  cursor  to  Test_Lib  in  Project_lib 
window. } 

<De£inition> 

{Move  cursor  to  Mat_Main  body.} 

<Object>  <Left  Arrow> 

<Code  (All  Worlds  )> 

c.  Change  package  body  by  deleting  an  unused  subprogram  body:  Delete 
pairwise  vector  multiplication  function  body  and  store  temporarily  in  a  sepa¬ 
rate  location.  Translate  into  PROJECT_LIB.  Create  executable  module. 
Observe  system  retranslation  behavior. 
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{At  the  end  of  step  9b  the  cursor 
is  in  the  Test^Lib  window;  return 
to  Project^Lib  window, } 

<Enclosing  Object> 

{Create  Ada  object  to  store  function  body. } 

<Object,  I> 

{Return  to  Project^Lib  directory. } 

<Enclosing  Object> 

{Move  cursor  to  Ve ct or_Manageme nt  body.  } 

<Definition> 

{Make  Vector^Managexxient  body 
incrementally  editable . } 

<Install  Unit> 

{Move  cursor  over  pairwise  vector 
multiplication  function  and  select  it.} 

<Object>  <Left  Arrow> 

{Move  cursor  to  anonymous  object  window 
and  copy  function  to  it . } 

<Region>  C 

{Move  cursor  back  to 

Ve  ct  or__Managetne  nt '  Body  window .  Move 
cursor  over  pairwise  vector  multiplication 
function  and  select  it.} 

<Object>  <Left  Arrow> 

{Delete  function  body. } 

<Object>  D 

{Return  Vector^Management  body  to  coded. } 

<Promot> 

{Move  cursor  to  Project_Lib  window.  } 

<Snclosing  Object> 

{Move  cursor  over  Test^Lib  window. } 

<Definition> 

{Move  cursor  over  Mat_^in  body.} 

<Object,  Left  Arrow>  {MatJMain  is  selected.} 
<Compilation  Make> 

d.  Change  package  body  by  adding  a  subprogram  body:  Add  back  painA^ise 
vector  multiplication  function  body.  Translate  into  PROJECT^LIB.  Create 
executable  module.  Observe  system  retranslation  behavior. 
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(At  the  end  of  step  9c  the  cursor 
is  in  the  Test^Lib  window;  return 
cursor  to  Project_Lib  window.} 

<Enclosing  Object> 

(Move  cursor  to  object 
containing  function  body.) 

<Def inition> 

(Return  to  Project^Lib  directory.) 

<Enclosing  Object> 

(Move  cursor  to  Vector_Management '  Body .  } 

<Def inition> 

(Make  Vector_Management  body  incrementally 
editable . ) 

<Install  Unit> 

(Open  edit  window  for  function  body.) 

<Object>  I 

(Move  cursor  to  window  holding  function  and 
select  function. } 

<Object>  <I*eft  Arrow> 

(Move  cxxrsor  to  Vector_Management  insertion 
window  and  copy  function 
to  it . } 

<Region>  C 

( Install  function  body . ) 

<Promot> 

(Code  Vector_Managexnent  body.) 

<Promot> 

(Move  cursor  to  Project_Lib  window. } 

<Enclosing  Object> 

(Move  cursor  to  Test_Lib  window. } 

<Definition> 

(Move  cursor  to  Mat_Main  body  and 
select  it . } 

<Object>  <Left  Arrow> 

<Code  (All  Worlds)  > 

e.  Change  a  package  specification  by  adding  a  subprogram  specification:  Add 
back  pairwise  vector  muitiplication  function  specification.  Translate  into 
PROJECT_LIB.  Create  executable  module.  Observe  system  retranslation 
behavior. 
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{At  the  end  of  step  9d  the  cursor  is 
in  the  Test^Lib  window;  return  cursor 
to  Project^Lib  window. } 

<Enclosing  Object> 

{Move  cursor  to  object  containing 
function  spec. } 

<Definition> 

{Return  to  Project^Lib  directory.} 

<Enclosing  Object> 

{Move  cursor  to  Vector^Managexnent '  Spec.  } 

<Definition> 

{Make  Vector_^nagexnent '  Spec 
incrementally  editable.} 

<Install  nnit> 

{Open  window  to  edit  function  spec. } 

<Object>  I 

{Move  cursor  to  window  holding 
function  spec  and  select  function. } 

<Object>  <Left  Arrow> 

{Move  cursor  to  Vector^Managexnent  ^  Spec 
declaration  insertion  window  and  copy 
function  to  it . } 

<Region>  C 
<Promot> 

{Note:  window  showing  units  that  would 

be  made  obsolete  by  promotion  opens 
(Mat^^Main'  Body)  .  Cursor  moves  to  this 
window.  Move  cursor  over  Mat  Main' Body 
and  select  it . } 

<Object>  <I-eft  Arrow> 

{Demote  Mat^Main  to  source  state.} 

<Source  Unit> 

{Move  cursor  back  to  Vector_Management 
insertion  window . } 

{Install  function  spec.} 

<Promot> 

{Code  Vector_Management '  Spec . } 

<Promot> 

{Move  cursor  to  Project_Lib  window. } 

<Enclosing  Object> 

{Move  cursor  to  Test_^Lib  window.  } 

<De  f init ion> 

{Move  cursor  to  Mat  Main' Body  and 
select  it . } 

<Object>  <Left  Arrow> 

<Code  (All  Worlds) > 

f.  Change  package  body  by  adding  comments:  Add  comments  to  package 
body  of  VECTOR_MANAGEMENT.  Translate  into  PROJECT_LIB.  Create 
executable  module.  Observe  system  retranslation  behavior. 

{Since  comments  can  be  added  to  a  coded  body,  no  retranslation  is 
required.) 
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(The  cursor  is  in  the  Test^Lib  window 
at  the  end  of  step  9e;  move  cursor  to 
Vector^^Management'  Body.  } 

<De  f inition> 

{Move  cursor  to  where  comment  is  to 
be  inserted  and  open  an  insertion 
window . } 

<Object>  I 
{Enter  comment.} 

<Promot> 

{Note:  comment  is  placed  into  body 

and  insertion  window  closes.  More  comments 

may  be  inserted  by  following  the  same  steps . } 

g.  Add  comments  to  package  specification  of  VECTOR_MANAGEMENT. 
Translate  into  PROJECT_LIB,  Create  executable  module.  Observe  system 
retranslation  behavior. 

{Since  comments  can  be  added  to  a  coded  specification,  no  retranslation  is 
required.} 

{The  cursor  is  in  the 
Vector_Management ' Body  window 
at  the  end  of  step  9f;  move  cursor  to 
Test_Lib  window. } 

<Enclosing> 

{Move  cursor  to  Vector_Management '  Spec .  } 

<Definition> 

{Move  cursor  to  where  comment  is  to 
be  inserted  and  open  an  insertion 
window. } 

<Object>  I 
{Enter  comment . } 

<Promot> 

{Note:  comment  is  placed  into  body 

amd  insertion  window  closes .  More  comments 

may  be  inserted  by  following  the  same  steps . } 


4.3.  Functionality  Checklist 


Activity 

Step  # 

Supported 

(Y/N) 

Observations 

Detailed  Design 

Create  system  skeleton . 

3 

No 

Code  Development  and  Translation 

Create  program  library . 

.  3 

Yes 

Create  prog.  lib.  interdep . 

Develop  package  specs 

.  6 

Yes 

create  package  spec . 

3 

Yes 

A  private  part  generator  Is  provided. 
Editor  is  syntax  directed. 

modify  package  spec . 

3 

Yes 

delete  package  spec . 

.  gen 

Yes 
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Develop  package  bodies 
create  package  bodies . 

A  null  body  generator  is  provided 


5,7  Yes 


modify  package  bodies .  5,7 

delete  package  bodies .  gen 

Query  and  manip.  prog.  Mb. 

list  unit  names .  8 

list  unit  types .  8 

list  prog.  lib.  interdep .  gen 

list  package  interdep .  8 

list  subprog,  interdep .  8 

determine  completeness .  8 

determine  recomp .  8 

remove  unit .  gen 

clear  prog,  lib .  gen 


Translate  code 

trans.  Into  a  prog,  lib .  3,5,7 

create  x-ref.  map .  6 

display  error  messages .  3,5,6 

list  subprog,  interdep .  8 

pretty  print  source  code .  gen 

Create  executable  Image .  6,8 

Execute  code 

halt/resumeAerminate  execution .  6 

trace  execution  path .  6 

clock  CPU  time  by  subprog .  gen 


Yes 

Yes 


Yes 

Yes 

Yes  Links.Display  command 

Yes 

Yes  Via  Xref  command 

Yes  Via  Compilation.Make  with  wildcard  or 

<Compile  (All  Worlds)>  key. 

Yes  Compilation.Make,  effort  only  switch  on. 

Yes  Bodies  must  be  removed  before  specs. 

Specs  cannot  be  removed  until  all 
dependent  units  have  been  demoted 
to  source. 

Yes  Compilation.Delete  with  wildcard, 

and  Library.Expunge  or 
Compilation.Destroy. 


Yes 

Yes 

Yes 

Yes 

Yes 

N/A  R1 000  links  at  run  time.  Pragma 
Main  forces  prelinkage. 


Yes  See  Unit  Testing  and 

Yes  Debugging  Experiment,  Chapter  5. 

No 


4.4.  Experiment  Answers 

Question  Response 

DD1  Describe  the  mechanics  of  Importing  data  from  the  OS. 

The  Rational  Environment  is  the  host  operating  system  for  the  R1000  com¬ 
puter.  Data  is  made  available  to  programs  and  command  procedures 
through  "operating  system"  routines.  Ail  of  these  routines  are  callable  Ada 
functions  or  subprograms. 

DD2  What  tools  are  provided  by  the  environment  to  monitor/query  CPU  and 

elapsed  time  for  a  tool,  memory  utilization  for  a  tool,  storage  require¬ 
ments  for  flies,  directories,  and  program  libraries? 

The  package  ITools.System_Utilities  provides  a  function  Cpu  that  returns  the 
elapsed  CPU  time  for  a  specified  or  current  job.  The  execution  of  a  tool  can 
be  the  specified  job.  The  memory  utilization  of  a  tool  can  be  monitored  by 
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the  procedures  What.Users  and  What.Jobs  which  return  information  about 
processes  in  the  system.  The  storage  requirements  for  a  tool  are  displayed 
using  the  library  listing.  Storage  requirements  for  objects  (files,  directories, 
and  program  libraries)  are  found  either  through  the  library  list  command  or 
the  package  !Tools.Directory_Tools. Statistics  function  0bject_Si2e.  The 
library  listing  command  also  provides  date  modified,  last  user  to  modify,  size 
and  class  of  objects,  and  status  of  Ada  objects  (archived,  source,  installed,  or 
coded.) 

Describe  the  extent  to  which  user  interface  customization  is  possible, 
Including  support  for  user-defined  command  procedures,  command 
aliases,  and  key  bindings. 

All  operations  in  the  R1000  Environment  are  performed  by  Ada  subprograms, 
which  can  be  bound  to  a  key  or  executed  from  a  command  window.  All  the 
procedures  that  constitute  the  R1000  Environment  can  be  incorporated  in 
user-written  procedures,  which  can  be  executed  from  command  windows  or 
bound  to  keys.  Since  Ada  procedures  can  be  renamed,  aliases  can  be  pro¬ 
vided  for  any  Environment  command  or  user-defined  procedure. 

The  R1000  terminal  provides  twenty  function  keys  and  three  modifier  keys 
(Shift,  Control,  and  Meta)  for  a  total  of  160  key  combinations  available  for 
binding.  Of  these,  96  are  bound  to  common  operations  in  the  Environment 
and  64  are  available  to  be  bound  to  user-created  procedures  or  to  other 
procedures  in  the  Environment.  Since  Rational  provides  a  keyboard  template 
that  indicates  which  procedure  is  bound  to  which  key  combination,  the  mul¬ 
tiplicity  of  key  combinations  is  easily  mastered  in  practice.  The  keyboard 
template  also  provides  space  for  recording  any  user-defined  key  bindings. 
Default  key  bindings  include  debugger  operation;  directory  traversal  and  list¬ 
ing;  help;  promotion  and  demotion  of  Ada  objects;  creation  of  directories, 
worlds,  and  text  files;  browsing  commands;  job  management;  and  system 
queries.  The  program  that  binds  procedures  to  a  key  can  specify  whether  the 
procedure  will  execute  immediately  or  appear  in  a  command  window  with 
prompts  for  the  procedural  parameters  provided.  In  this  experiment  user- 
written  procedures  that  were  used  to  collect  size  and  timing  statistics  were 
bound  to  the  keyboard. 

Command  windows  provide  a  block  within  which  any  procedure  visible  in  the 
current  default  context  can  execute.  Command  windows  use  a  standard  con¬ 
text  clause  that  makes  all  common  procedures  for  operating  the  Environment 
visible.  Users  can  edit  the  context  clause  of  a  command  window  to  make  any 
subprogram  they  want  visible.  Procedures  can  be  created  (and  bound  to 
keys)  that  will  create  a  customized  command  window.  When  a  procedure 
name  has  been  typed  into  a  command  window,  a  named  parameter  associ¬ 
ation  for  the  procedure  can  be  generated  with  the  key  Compit.  Associated 
with  each  parameter  is  a  prompt.  If  a  parameter  has  defaults  then  the 
defaults  appear  in  the  prompt.  If  there  is  no  default  for  the  parameter,  the 
type  or  subtype  indication  appears  in  the  prompt.  The  user  can  move  from 
prompt  to  prompt  using  the  next  item  key. 

A  user  indicates  at  login  the  name  of  the  current  session.  Associated  with  a 
session  name  is  an  extensive  set  of  switches  for  modifying  the  operating 
characteristics  of  the  Environment.  Among  other  things,  switches  control  the 
layout  of  the  screen  and  the  information  recorded  in  system  log  files.  Users 
can  maintain  as  many  sessions  and  associated  sets  of  switches  as  they  de¬ 
sire. 

When  a  user  logs  in,  the  system  looks  for  an  Ada  program  called  login  in  the 
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user’s  home  directory  and  executes  it.  Login  can  perform  any  additional 
customization  of  the  Environment  not  provided  by  session  switches  such  as 
selecting  a  directory  in  which  to  start  work.  Another  procedure, 
Rational_Commands  in  the  user’s  home  directory  will  perform  any  key  bind¬ 
ings  the  user  requires  that  are  global  to  all  sessions.  The  procedure  login  will 
always  be  invoked  upon  a  user  login,  while  Rational_Commands  will  only  be 
invoked  if  the  user  is  logging  in  from  a  Rational  Terminal.  Separating  key 
binding  commands  from  the  login  procedure  prevents  the  misapplication  of 
bindings  to  an  inappropriate  terminal.  Templates  to  construct 
Rational_Commands  and  other  Environment-supported  terminals  can  be 
found  in  !Machine.Editor_Data. 

DD4  Describe  the  mechanics  of  using  the  environment  to  define  objects  and 

operations  during  the  detailed  design  process. 

The  Rational  Environment  provides  no  support  for  graphical  design. 

DD5  Describe  the  mechanics  of  creating  a  program  library. 

In  the  Rational  Environment  any  directory  or  world  can  serve  as  a  program 
library.  Directories  or  worlds  are  created  by  the  procedures  Create_Directory 
and  Create_World  in  package  iCommands. Library.  The  procedures  are 
bound  to  function  keys  <Create  Directory>  and  <Create  World>.  Directories 
or  worlds  are  easily  created  by  pressing  these  keys  and  then  typing  the  name 
of  the  directory  or  world  in  response  to  the  prompt  appearing  in  the  command 
window. 

DD6  What  are  the  CPU  and  clock  times  for  creating  a  program  library? 

CPU  Time:  0.70  seconds.  Wall  Clock  Time:  1.73  seconds 

DD7  What  are  the  space  utilization  ramifications  of  creating  a  program 

library? 

Directory  creation  consumed  7426  bytes. 

DD8  How  easy/difficult  Is  It  to  create  a  program  library? 

Very  easy;  the  creation  requires  a  single  keystroke  followed  by  typing  the 
name  of  the  library  in  response  to  a  prompt,  followed  by  the  <Promot>  key. 

DD9  Describe  the  mechanics  of  entering  Ada  source  code:  package  specifi¬ 

cations,  package  bodies,  subunits,  and  subprograms. 

The  R1000  does  not  maintain  separate  files  for  source  code,  object  code, 
and  executable  images;  it  maintains  one  Ada  object,  which  may  be  in  one  of 
four  states,  archived,  source,  installed  or  coded.  Initial  entry  of  a  unit  using 
the  Ada  Object  Editor  creates  an  image  in  source  state.  The  Ada  unit  can  be 
demoted  to  archived  state,  which  is  much  more  compact  than  the  source 
state.  In  archived  state,  the  unit  need  not  be  syntactically  or  semantically 
correct,  and  cannot  be  edited.  The  unit  may  be  promoted  back  to  source 
state.  Units  in  the  source  state  can  be  freely  edited.  Installed  units  are 
syntactically  and  semantically  correct  and  are  visible  to  other  units.  Only 
those  portions  of  installed  units  on  which  there  are  no  dependencies  can  be 
edited.  Declarations  and  statements  may  be  freely  added  to  installed  units. 
Coded  units  have  had  machine  code  generated.  An  Ada  unit  in  the  coded 
state  cannot  be  edited  except  for  the  addition,  deletion,  and  modification  of 
comments;  it  must  first  be  demoted  to  the  installed  or  source  state. 

The  R1000  editor  can  create  either  Ada  objects  or  text.  What  the  editor 
creates  is  determined  by  the  method  of  invoking  it.  To  create  text,  the  editor 
is  invoked  by  pressing  the  create  text  key  and  typing  the  name  of  the  text  file 
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desired  in  response  to  the  prompt  generated  by  the  keystroke.  The  name  of 
the  text  file  appears  in  the  directory  listing  and  a  window  into  which  text  may 
be  entered  is  opened.  To  create  an  Ada  object,  the  user  presses  the  object 
key  followed  by  "I"  or  "i"  for  insert.  This  causes  a  window  into  which  the 
object  may  be  typed  to  be  opened.  When  the  object  is  promoted  to  the 
installed  state  for  the  first  time,  the  name  of  the  compilation  unit  appears  in 
the  directory  listing.  Prior  to  the  first  promotion  the  object  is  anonymous 
(does  not  appear  in  directory  listing)  or  appears  with  a  system-generated 
name  if  certain  operations  such  as  committing  the  object  to  disk  are  per¬ 
formed.  Subunits  cannot  be  created  as  separate  Ada  objects.  They  are 
generated  either  by  entering  a  procedure  body  in  line,  selecting  the  proce¬ 
dure  with  the  object  select  keys  and  entering  the  Make_Separate  command 
in  a  command  window  attached  to  the  object  being  edited,  or  by  selecting  a 
subunit  declaration  and  pressing  the  edit  key,  which  creates  a  window  con¬ 
taining  a  skeleton  of  the  subunit.  Subunits  can  be  brought  in  line  with  the 
Makejnline  command. 

A  bug  exists  in  the  editor  whereby  complex  editing  operations  make  it  fail  to 
recognize  a  legal  Ada  statement.  This  bug  was  bypassed  by  deleting  small 
sections  of  source  and  re-entering  them.  The  observed  frequency  of  the 
editor  problem  decreased  from  the  GammaO  and  Gammal  Releases  of  the 
Rational  Environment.  The  problem  was  observed  only  once  in  conducting 
the  experiment  using  the  Delta  Release.  The  power  of  the  editor  outweighs 
this  problem. 

Entering  an  Ada  object  is  easy  and  efficient  once  the  R1000  editor  is  mas¬ 
tered.  Since  the  editor  is  highly  sensitive  to  environment,  its  capabilities  are 
more  fully  described  in  the  answer  to  DD10. 

Is  the  editor  sensitive  to  the  environment? 

The  Rational  Environment  is  controlled  either  through  keys  to  which  environ¬ 
ment  procedures  are  bound  or  through  command  windows.  Since  the  editor 
is  used  for  editing  Ada  objects,  text,  and  command  windows,  it  is  the  inter¬ 
face  to  the  Rational  Environment:  a  user  never  leaves  the  editor.  Even  when 
a  user  is  supplying  input  to  a  user-developed  Ada  program  through  a  window 
generated  by  TextJO,  the  editor  functions  are  available.  A  user  can,  for 
example,  use  editor  functions  to  copy  part  of  a  window  generated  by  Text_IO 
into  a  request  for  input  generated  by  TextJO. 

The  Ada  Object  Editor  offers  syntactic  and  semantic  completion  of  constructs 
and  interactive  syntax  and  semantics  checking.  The  syntax-sensitive  fea¬ 
tures  and  local  semantics  are  accessed  through  the  format  key,  and  the 
semantics-sensitive  features  are  accessed  through  the  complete  and  seman- 
ticize  keys. 

When  the  format  key  is  pressed  to  complete  the  syntax  of  an  Ada  construct, 
the  editor  prompts  for  missing  elements.  For  example,  if  the  programmer 
types  "procedure  Foo  is"  and  then  presses  the  format  key,  the  editor 
responds  by  generating  the  following  completion; 

procedure  Foo  is 
begin 

[statement] 
end  Foo; 

The  cursor  is  positioned  on  the  prompt  "[statement]."  The  programmer  can 
move  between  prompts  with  the  next  item  and  previous  item  keys.  Prompts 
disappear  when  the  programmer  types  on  them.  The  syntactic  completion 
capability  of  the  editor  allows  a  programmer  to  prevent  many  syntax  errors  by 
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having  the  editor  format  Ada  constructs.  The  format  key  wiii  also  correct 
some  syntax  errors  of  omission  by  performing  syntactic  completion. 

The  editor  knows  all  the  semantic  information  available  in  any  library.  The 
editor  uses  this  information  to  offer  semantic  completion  of  subprogram  calls. 
The  user  enters  the  name  of  a  subprogram  in  an  Ada  object  and  selects  it 
with  the  object  select  keys.  When  the  complete  key  is  pressed,  the  editor 
generates  a  named  parameter  association  for  the  subprogram,  with  prompts 
for  the  actual  values  giving  the  type  of  the  expression  required.  If  a 
parameter  has  a  default  value  then  this  is  supplied  in  the  named  association 
instead  of  a  prompt.  When  the  complete  key  is  used  to  generate  named 
parameter  associations,  code  containing  a  semantic  error  will  be  generated  if 
all  of  the  following  conditions  are  true: 

1 .  The  procedure  being  completed  is  from  a  package  in  the  with 
clause  of  the  unit  being  edited. 

2.  There  is  no  use  clause  for  the  package. 

3.  The  parameter  has  as  a  default  value  of  a  type  declared  in  the 
package  in  the  with  clause. 

4.  The  default  value  is  not  written  using  the  dot  notation  to  include 
the  package  name. 

In  these  circumstances,  the  default  copied  into  the  parameter  association  will 
be  undefined. 

In  addition  to  syntactic  and  semantic  completion,  the  editor  provides  inter¬ 
active  syntax  and  semantics  error  correction  with  the  format  and  semanticize 
keys  respectively.  When  syntax  or  semantics  errors  are  found,  they  are  un¬ 
derlined.  The  user  can  move  between  errors  discovered  using  next  item  and 
previous  item  keys.  Explanations  of  each  error  are  available  by  pressing  the 
explain  item  key.  By  performing  syntax  and  semantics  checks  after  every 
statement  or  small  group  of  statements,  a  programmer  can  be  assured  that 
when  the  last  line  of  a  program  has  been  entered  and  checked,  the  entire 
program  is  completely  correct — both  syntactically  and  semantically. 

is  the  editor  an  OS  editor  or  is  It  specific  to  the  environment? 

The  editor  is  specific  to  the  Rational  Environment  and  the  Ada  language. 

Describe  the  mechanics  of  translating  a  compilation  unit  Into  a  speci¬ 
fied  program  library. 

A  program  library  is  either  a  directory  or  a  world.  An  Ada  object  will  be 
compiled  into  the  library  in  which  it  was  inserted.  The  procedure  for  inserting 
an  Ada  object  into  a  library  is  described  in  DD9.  The  Rational  system  divides 
compilation  into  two  separate  stages: 

1.  The  creation  of  the  DIANA  tree  that  represents  a  syntactically 
and  semantically  correct  Ada  program. 

2.  Code  generation. 

The  DIANA  tree  is  created  and  incrementally  checked  for  syntactic  and 
semantic  correctness  in  the  editor.  In  the  source  state  the  DIANA  tree  can  be 
freely  edited.  In  the  installed  state  elements  can  be  added  to  the  tree,  and 
elements  on  which  nothing  is  dependent  can  be  changed  or  deleted.  In  the 
coded  state  the  DIANA  tree  cannot  be  edited  except  for  its  comment  nodes. 
While  editing,  each  time  the  format  key  is  pressed,  the  syntax  of  new  text 
entered  is  checked.  Each  time  the  semanticize  key  is  pressed  the  entire  unit 
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is  checked  for  semantic  correctness.  At  any  point  when  the  DIANA  tree  is 
syntactically  and  semantically  correct,  the  compilation  unit  can  be  made 
visible  in  the  program  library  by  promoting  it  to  either  the  installed  or  coded 
state.  A  coaect  DIANA  tree  in  the  coded  state  may  be  incomplete  in  the 
sense  that  its  image  still  contains  prompts  indicating  incomplete  Ada  con¬ 
structs.  Programs  containing  incomplete  Ada  constructs  will  execute  up  to 
the  time  that  a  call  is  made  to  an  incomplete  construct,  at  which  time  the 
system  raises  Program_Error. 

To  perform  promotion  either  the  unit  name  is  highlighted  in  a  directory  listing 
or  the  cursor  is  placed  in  an  image  of  the  Ada  object.  The  user  then  has  the 
following  alternatives: 

1 .  Press  the  promote  key,  which  moves  object  up  one  state  (from 
source  to  installed  or  installed  to  coded). 

2.  Press  the  install  key,  which  moves  the  object  to  the  installed 
state  (from  either  the  source  or  coded  state). 

3.  Press  the  code  key,  which  moves  the  object  to  the  coded  state 
(from  the  source  or  installed  state). 

The  R1000  also  provides  procedures  for  converting  text  files  into  Ada  ob¬ 
jects.  The  primary  use  of  these  procedures  is  not  program  development  but 
rather  importing  Ada  programs  from  other  computers,  such  as  when  running 
the  Ada  Compiler  Validation  Suite. 

How  easy/difficult  is  it  to  translate  a  compilation  unit? 

Very  easy.  One  keystroke  will  translate  a  unit  when  the  cursor  is  in  an  image 
of  the  object  or  when  the  object  has  been  selected  in  a  directory  listing  with 
the  object  select  keys. 

How  much  translator  error  correction  is  automated? 

The  R1000  translator  is  designed  to  compile  incrementally  on  a  statement- 
by-statement  basis  and  is  intended  to  be  used  frequently  during  interactive 
program  editing.  Syntax  and  semantics  checking  are  separate  operations 
that  the  user  can  invoke.  They  are  integrated  with  the  editor  so  that  correc¬ 
tions  made  by  the  translator  are  inserted  in  the  source.  To  this  end  the 
primary  error  correction  performed  by  the  translator  is  syntactic  completion. 

How  tolerant  of  simple  syntax  errors  Is  the  translator? 

Very  tolerant.  It  will  correct  many  syntax  errors  of  omission. 

How  informative  are  the  translator  error  messages? 

For  interactive  incremental  compilation,  translator  error  messages  are  of  two 
types.  When  an  error  is  discovered  it  is  underlined  in  the  source.  An  ex¬ 
planation  of  any  underlined  error  can  be  requested  with  the  explain  item  key. 
Often,  having  the  location  of  the  error  pointed  out  with  underlining  is  sufficient 
for  the  programmer  to  immediately  locate  the  problem.  Sometimes  the  un¬ 
derlining  provided  by  the  syntax  checker  is  misleading  in  that  a  correct  con¬ 
struct  preceding  the  error  is  underlined.  In  these  cases  the  message  pro¬ 
duced  by  the  explain  item  key  will  usually  provide  a  clue  that  allows  location 
of  the  error. 

Semantic  error  messages  are  usually  straightforward  and  informative.  Ex¬ 
amples  are: 

"Operator  contains  no  return  statement" 

"INDEX  is  undefined" 
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A  syntax  error  message  is  expressed  in  terms  of  an  unexpected  token  recog¬ 
nized  by  the  parser  and  a  list  of  expected  tokens.  When  the  list  of  what  was 
expected  is  short  this  is  helpful.  For  example,  the  function  declarations  in  the 
matrix  management  specification  that  separates  parameters  with  commas 
rather  then  semicolons  generates  an  underlining  of  the  comma  and  the  fol¬ 
lowing  message: 

Saw  expected: 

A  long  message  from  the  parser  is  less  helpful.  For  example,  the  missing  "is" 
in  the  declaration  of  pairwise  vector  multiplication  in  Vector_Management 
body  generates  an  underlining  of  U_Len  and  the  following  message: 

Saw  "U_LEK",  expected:  "eof", 

tl  It  II  .^11  M^ll  II '1^11  II.  II  II  /M 

•  •  r  •  “  ^  f  t  ^  t  ^  t  t  \  r 

It  \  It  tt  ^  II  tt  /  Tt  tl  4,  It  It  r  Tt  It  _  It  It  II  tt  I  II  II  Tt 

/  r  r  /  r  *  r  ^  r  f  r  r  \  r  •  r 

"and",  "in",  "is",  "loop",  "mod",  "not", 

"or",  "range",  "rem",  "renames",  "then",  "xor" 

The  Environment  is  designed  with  the  intent  that  the  semantics  and  syntax 
checking  capabilities  be  used  frequently.  Proper  use  of  these  facilities  will 
insure  that  the  scope  within  which  any  part  of  the  program  can  be  incorrect  is 
kept  small. 

The  Environment  also  provides  facilities  for  compiling  text  files.  The  compi¬ 
lation  process  turns  them  into  Ada  objects.  The  error  reporting  provided  by 
the  procedures  used  to  compile  text  files  is  rudimentary  compared  to  the 
error  reporting  available  when  performing  interactive  incremental  compilation 
in  the  ^itor.  An  error  report  for  a  text  file  compilation  consists  of  the  line 
number  and  column  in  which  the  error  occurred,  the  token(s)  expected,  and 
the  token  found.  After  one  error  is  found,  the  text  compilation  procedures 
abandon  the  compilation  effort. 

What  are  the  CPU  and  elapsed  times  for  translating  a  compilation  unit 
into  a  specified  library? 

The  following  times  include  both  installation  and  coding  of  the  given  proce¬ 
dure. 


Time  for  Vector_Managemeiit  specification 
Elapsed  Time :  5.52  seconds 
CPU  Time :  2.48  seconds 

Time  for  Matrix  Management  specification 
Elapsed  Time :  3.00  seconds 
CPU  Time:  1.37  seconds 

Time  for  Vector_Management  body 
Elapsed  Time :  6.13  seconds 
CPU  Time:  3.09  seconds 

Time  for  Vec_Main  body 
Elapsed  Time :  3.83  seconds 

CPU  Time :  2.76  seconds 

What  are  the  space  utilization  ramifications  of  translating  a  compilation 
unit  into  a  specified  program  library? 

The  semantics  of  a  Rational  library  are  conveyed  by  both  the  Ada  objects 
contained  in  a  library  and  by  information  maintained  in  the  enclosing  context. 
The  division  between  these  two  is  not  clear.  Therefore,  space  utilization  is 
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reported  as  the  sum  of  the  change  in  library  size  generated  by  installing  an 
object  and  the  size  of  an  object  installed.  (Note  that  the  size  of  a  directory 
does  not  include  the  size  of  the  objects  contained  within  it;  it  includes  only  the 
information  in  the  directory  itself.  Some  information  separate  from  an  Ada 
object  is  generated  in  the  directory  by  installing  an  object).  No  space  is 
consumed  by  coding;  only  installation  consumes  space. 

Space  for  Vector_Manageiaent  specification 
Library  space:  125  bytes 

Object  size:  13281  bytes 

Space  for  Matrix_Management  specification 
Library  space :  125  bytes 

Object  size:  11365  bytes 

Space  for  Vector  Management  body 
Library  space:  125  bytes 

Object  size:  13083  bytes 

Space  for  Vec_Main  body 
Library  space:  1365  bytes 
Object  size:  34386  bytes 

Describe  the  mechanics  of  using  the  environment  to  design  data  struc¬ 
tures,  program  units,  program  units  interfaces,  and  controi  fiows. 

No  graphic  design  tools  are  available. 

is  a  graphical  Interface  supported? 

No.  The  Rational  Environment  does  support  a  character-oriented,  windowing 
interface  on  a  66  line  by  80  column  screen.  The  number  of  windows  is  user 
definable,  with  from  one  to  four  windows  being  usable.  The  Rational  windows 
do  not  overlap;  they  split  the  screen  into  horizontal  segments. 

How  much  source  code  generation  Is  automated  (e.g.  null  body  gener¬ 
ation  and  completion  of  matching  begin  ..  end  statements)? 

Both  a  private  part  generator  and  a  body  part  generator  are  available  with 
single  keystrokes  in  the  editor.  The  body  part  generator  can  create  bodies 
for  single  procedures  and  functions,  as  well  as  packages;  however,  it  fails 
when  attempting  to  create  a  body  part  for  a  task  with  no  entries.  Further 
automatic  code  generation  capabilities  are  described  in  the  answer  to  DD10. 

What  are  the  CPU  and  elapsed  times  for  translating  a  compiiatlon  unit 
Into  a  specified  program  library? 

SeeDD17. 

Describe  the  mechanics  of  creating  Inter-program  library  dependencies. 

A  program  unit  contained  in  library  A  is  made  visible  in  library  B  by  executing 
the  Unks.Add  command  in  library  B  passing  the  pathname  of  the  unit  in 
library  A.  Use  of  wildcards  in  the  pathname  allows  making  more  than  one  unit 
in  A  visible  to  B  with  one  Unks.Add  command.  The  Rational  Environment 
checks  dependencies  across  libraries  so  that  a  change  to  a  unit  in  A  will  not 
be  permitted  if  it  would  make  obsolete  a  unit  in  B.  In  general,  the  Rational 
Environment  will  not  allow  changes  in  one  unit  that  make  another  unit  obso¬ 
lete  unless  the  unit  that  would  be  made  obsolete  is  demoted  to  the  source 
state.  The  Environment  provides  the  Compilation. Demote  procedure  (which 
is  bound  to  the  keyboard)  for  performing  the  demotion  of  all  units  dependent 
on  a  given  unit. 
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Describe  the  mechanics  of  creating  an  executable  module. 

Because  the  Rational  Environment  performs  linking  at  runtime  this  question 
is  inapplicable.  Linking  before  runtime  can  be  forced  by  including  the  pragma 
Main  in  a  main  procedure.  Unking  then  occurs  when  the  main  unit  is 
promoted  to  the  coded  state.  This  would  be  done  only  if  speed  of  program 
execution  had  become  a  problem. 

How  easy/difficult  Is  It  to  create  an  executable  module? 

See  DD24. 

What  are  the  CPU  and  elapsed  times  necessary  for  creating  an  ex¬ 
ecutable  module? 

See  DD24. 

What  are  the  space  utilization  ramifications  of  creating  a  executable 
module? 

See  DD24. 

How  Informative  are  the  execution  time  error  messages? 

When  an  exception  is  raised,  the  Rational  Environment  reports  only  the  name 
of  the  exception  and  the  name  of  the  package  in  which  it  was  raised. 

Describe  the  mechanics  of  executing  a  module,  Including  I/O  redirec¬ 
tion,  execution  Interruption  and  resumption  and  termination. 

Modules  are  executed  by  promoting  a  command  window  containing  the  name 
of  the  module.  The  Rational  Environment  generates  humanly  readable  out¬ 
put  and  obtains  input  from  users  through  Standardjnput  and 
Standard_Output  of  TextJO.  Both  normally  default  to  an  editor  window.  For 
any  particular  job  Standardjnput  and  Standard_Output  can  be  reset  to  be 
any  text  file  by  using  the  procedure  Program.Run_Job.  The  file  names  of  the 
desired  input  and  output  files  are  passed  to  Run_Job  as  parameters,  as  is 
the  procedure  name.  Output  can  also  be  redirected  for  any  particular  job 
using  Log.Set_Output.  Run_Job  is  also  used  for  scheduling  a  job  to  be  run 
at  a  given  time.  Programs  running  in  the  background  can  be  stopped, 
started,  and  killed  with  the  Job.Enable,  Job.Disable,  and  Job. Kill  commands. 
The  user  can  connect  to  any  job  with  a  Job.Connect  command  and  can  dis¬ 
connect  from  the  current  job,  forcing  it  to  run  in  the  background,  by  typing 
Control  G. 

Describe  the  environment's  mechanism  for  enforcing  source  code,  ob¬ 
ject  module,  and  executable  module  consistency. 

By  combining  the  functions  of  source  code,  object  code,  and  executable  im¬ 
age  into  the  Ada  object,  the  Rational  Environment  ensures  consistency.  Note 
that  the  Environment  will  not  allow  a  compilation  unit  A  that  depends  on 
another  compilation  unit  B  to  remain  in  the  coded  or  installed  state  if  changes 
are  made  in  B  that  make  A  obsolete. 

Does  the  environment  permit  browsing  of  Ada  Source  code  at  varying 
levels  of  abstraction? 

Once  Ada  code  has  been  installed,  browsing  of  its  uses  and  definition  can  be 
done  with  a  single  keystroke  by  selecting  a  construct. 

What  are  the  space  utilization  ramifications  of  browsing  a  compilation 
unit? 

Reading  an  object  using  the  editor  does  not  aeate  another  version  of  the 
object. 
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How  easy/dlftlcult  is  It  to  find  an  Ada  object,  subprogram  specification, 
or  body  when  Its  file  or  package  location  is  unknown? 

The  Rational  Environment  provides  a  browsing  facility  for  locating  definitions 
of  objects  and  subprograms.  By  highlighting  a  name  with  the  object  selection 
keys  and  then  pressing  the  definition  key,  the  place  where  an  object,  sub¬ 
program,  or  compilation  unit  is  defined  will  automatically  be  displayed.  If  the 
definition  is  in  the  current  image,  the  window  on  the  image  will  be  reposi¬ 
tioned  to  show  the  definition.  Otherwise,  another  window  will  be  opened  to 
show  the  definition.  The  Environment  provides  markers  tor  a  series  of  defini¬ 
tion  requests  so  that  the  users  path  through  a  series  of  windows  can  be 
retraced  to  the  starting  point.  The  Environment  provides  an  Ada  Other  Part 
key  to  automatically  bring  a  specification  into  view  from  a  body,  or  to  bring  a 
body  into  view  from  a  specification. 

How  well  Integrated  are  the  following  environment  tools:  browser,  edi¬ 
tor,  translator,  and  program  library  utilities. 

The  browser,  editor,  and  translator  are  completely  integrated.  Editing  an  ob¬ 
ject  automatically  places  the  user  in  the  library  into  which  the  object  is  com¬ 
piled. 

Describe  the  mechanics  of  querying  and  manipulation  of  a  program 
library. 

Commands  accessed  with  a  single  key  press  will  be  indicated  by  the  name  of 
the  key  enclosed  in  angle  brackets.  For  example,  the  Create  Ada  key  will  be 
shown  as  <Create  Ada>. 

Manipulation  of  Libraries 

Two  commands,  <Create  World>  and  <Create  Directory>  create  a  library 
within  the  current  context.  A  full  pathname  tor  the  directory  or  world  can  also 
be  supplied. 

The  current  library  is  defined  by  the  cursor  position;  it  will  be  either  the  world 
or  directory  listing  containing  a  cursor  or  the  world  or  directory  containing  the 
object  in  whose  image  the  cursor  is  positioned. 

Libraries  can  be  cleared  by  entering  the  compilation.delete  command  with  the 
all  object  wildcard  in  a  command  window  opened  on  the  library.  The 
library  pathname  could  also  be  supplied  as  a  prefix  to  the  wildcard. 

Cleared  libraries  are  deleted  by  highlighting  their  name  in  the  context  that 
encloses  them  and  then  pressing  the  <Object>  D  key  sequence. 

Interllbrary  Linkage 

A  compilation  unit  in  library  A  may  reference  a  compilation  unit  in  library  B  by 
CTeating  a  link  to  the  other  compilation  unit  in  library  A.  Links  are  manipulated 
with  link  commands  and  are  associated  only  with  worlds,  not  directories. 
Links  to  a  world  outside  (or  inside)  a  given  world  are  called  external  links. 
Links  are  also  required  to  make  units  in  a  single  program  library  visible  to 
each  other.  Such  links  are  called  internal  links  and  are  automatically  gener¬ 
ated  by  translating  into  a  library.  The  automatic  generation  of  internal  links 
can  be  disabled  with  a  session  switch.  The  link  commands  are  as  follows: 

Links.Add  takes  the  pathname  of  the  unit  tor  which  a  link  is  to  be  created. 
The  name  of  the  link  is  by  default  the  name  of  the  unit.  It  a  name  other  than 
the  name  of  the  unit  is  specified,  then  the  referenced  unit  is  effectively 
renamed  by  the  link. 

Links. Copy  copies  the  links  or  a  subset  of  the  links  in  one  world  to  another 
world. 
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Links.Display  shows  all  links  associated  with  a  world. 

Links. Delete  deletes  a  link  or  multiple  links  through  use  of  wildcards. 

Links. Dependents  shows  all  Ada  units  dependent  on  a  link. 

Links.Display  shows  all  links  in  a  world. 

Links. Replace  replaces  a  specific  link  with  another  link 

Several  other  link  commands  exist  that  offer  subtle  variations  on  the  ones 
above. 

Manipulation  of  Ada  Objects 

Ada  units  are  made  visible  to  other  units  in  a  library  by  promoting  them  to  the 
installed  state  and  made  invisible  to  other  units  by  demoting  them  to  the 
source  state.  The  method  of  inserting  an  Ada  object  into  a  library  was  de¬ 
scribed  in  the  answer  to  DD9.  They  are  deleted  from  the  library  by  selecting 
them  with  the  object  select  keys  and  pressing  the  object  key  followed  by  "D" 
or  "d"  for  delete.  An  object  cannot  be  deleted  until  all  the  units  that  depend 
on  it  have  been  demoted  to  the  source  state.  Units  may  be  copied  from  one 
library  to  another  with  the  Library. Copy  and  Library. Move  commands. 

Library  Queries 

Directory  listings  (which  include  all  objects  in  a  world,  or  directory,)  can  be  set 
to  indicate  the  type  of  an  Ada  object  (procedure  body,  package  spec  or  body, 
subunit).  This  can  be  set  either  while  in  a  directory  or  by  session  switches. 
Session  switches  can  be  set  to  cause  the  directory  listings  to  display  the 
state  of  Ada  object  (source,  installed,  or  coded),  although  this  significantly 
slows  listings  of  long  directories. 

Listings  of  only  the  Ada  objects  in  a  library  together  with  their  state  (archived, 
source,  installed,  or  coded)  and  the  type  of  unit  can  be  generated  by  the 
Ada_List  command.  Ada_List  has  one  deficiency:  it  does  not  show  subunits 
in  the  library  that  appear  in  directory  listings.  Further  information  about  all 
objects  in  a  library  such  as  l£ist  modifier,  date  of  last  modification  and  size 
can  be  obtained  with  the  Library. Verbose_List  command.  A  listing  of  the  files 
in  a  library- (which  holds  text  or  data)  can  be  obtained  with  Library. File_List 
command. 

The  command  Compilation_Make,  with  the  effort-only  switch  set  to  true, 
shows  all  compilation  activity  required  to  bring  the  transitive  closure  of  a 
given  unit  to  a  given  state  (installed  or  coded).  Compilation_Make  will  not 
show  missing  bodies.  However,  a  program  exception  will  be  raised  during 
execution  if  an  empty  body  is  required  during  execution. 

The  Xref.Uses  command  generates  a  listing  of  all  constructs  upon  which  a 
given  unit  depends. 

The  Xref.Used_By  will  generate  a  listing  of  all  units  dependent  on  a  given 
construct. 

A  series  of  parameters  controls  the  granularity  with  which  the  Xref  commands 
display  dependency  information. 

How  easy/difticult  Is  It  to  manipulate  and  query  the  program  library? 

Most  library  query  and  manipulation  operations  are  performed  with  either  one 
or  two  keystrokes  or  by  executing  one  command  from  a  command  window. 

The  following  note  applies  to  questions  DD37  through  DD42.  The  Rational 
Environment  does  not  allow  alteration  of  coded  Ada  units  except  for  altera¬ 
tion,  addition,  and  deletion  of  comments.  Thus,  to  make  changes  other  than 
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to  comments,  the  unit  being  changed  must  be  demoted  to  the  installed  state. 
If  other  units  are  dependent  on  some  part  of  a  compilation  unit  being 
changed,  then  all  units  involved  must  be  brought  to  the  source  state  before 
changes  can  be  made.  However,  if  upwardly  compatible  changes  are  made 
(such  as  adding  type  declarations  to  a  specification)  then  dependent  units 
need  not  be  demoted.  If  changes  are  made  to  a  package  body,  it  must  be 
demoted  to  the  installed  state,  and  then  changes  can  be  made  incrementally. 
Moving  dependent  units  to  the  installed  state  is  automatic  when  a  given  unit 
is  demoted  to  the  installed  state.  Moving  dependent  units  to  the  source  state 
is  accomplished  with  the  Compilation.  Demote  procedure,  which  is  bound  to 
the  keyboard. 

This  behavior  is  unlike  that  of  a  conventional  edit,  compile,  link  system  in  that 
the  demotions  must  take  place  before  editing  is  permitted.  One  might  say 
that  decompilation  behavior  precedes  recompilation  behavior.  The  require¬ 
ment  that  units  dependent  on  a  declaration  in  a  given  unit  be  demoted  to  the 
source  state  prior  to  making  changes  ensures  that  the  system  will  never  be  in 
an  inconsistent  state. 

What  Is  the  system  recompilation  behavior  resulting  from  modifying  a 
referenced  package  specification? 

To  modify  the  Vector_Management  specification,  it  had  to  be  demoted  to  the 
installed  state.  This  automatically  demoted  all  dependent  units  to  the  in¬ 
stalled  state.  Before  the  specification  of  the  pairwise  vector  multiplication 
function  could  be  incrementally  deleted,  the  Rational  Environment  required 
that  the  units  depending  on  that  specification,  Vec_Main  and 
Vector_Management  body,  be  demoted  to  the  source  state.  A  system  recom¬ 
pilation  using  Mat_Main  as  the  main  procedure  produced  the  following 
results; 

Vector  Menagenent  body  was  Installed. 

The  following  were  moved  from  installed  to  coded: 

Matrix_Management  spec 

Mat_Main  body 

Vector_Management  body 

Matrix_Management  body 

Get_Col  body 

Get_Row  body 

What  Is  the  system  recompilation  behavior  resulting  from  modifying  a 
subprogram  body  In  a  package? 

Only  package  had  to  be  recompiled,  not  system. 

What  Is  the  system  recompilation  behavior  resulting  from  deleting  a 
subprogram  body  In  a  package? 

Only  package  had  to  be  recompiled,  not  system. 

What  Is  the  system  recompilation  behavior  from  adding  a  subprogram 
body  to  a  package  body? 

Only  package  body  had  to  be  recompiled,  not  system. 

What  Is  the  system  recompilation  behavior  resulting  from  adding  a  sub¬ 
program  specification  to  a  package  specification? 

Same  as  DD37  except  that  Mat_Main  had  to  be  moved  to  source  before  the 
function  specification  could  be  added  to  Vector_Management  spec. 

What  is  the  system  recompilation  behavior  resulting  from  adding  com¬ 
ments  to  a  package  body? 


CMU/SEI-88-TR-21 


109 


DD43 

General  Questions 
Functionality 

DD44 


DD45 


DD46 

User  Interface 

DD47 


No  recompilation  (or  compilation).  Comments  can  be  added  to  a  coded  unit 
without  moving  it  from  the  coded  state. 

What  Is  the  system  recompilation  behavior  resulting  from  adding  com¬ 
ments  to  a  package  specification? 

See  DD42. 


Describe  the  mechanics  of  using  the  online  help  facility. 

The  help  facility  is  accessed  by  using  five  keys:  <Help>,  <Help  on  Help>, 
<Help  on  Key>,  and  the  <Prompt  For>  <Help>  combination.  <Help  on  Help> 
key  opens  a  window  describing  how  to  use  the  other  help  keys. 

<Help  on  Key>  prompts  for  a  keystroke  or  two  keystroke  sequence.  In  key¬ 
stroke  sequences,  the  first  key  always  indicates  the  entity  of  interest  (object, 
region,  window,  image,  line,  work,  or  mark)  and  the  second  key  indicates  an 
operation  to  be  performed  on  the  entity,  such  as  "D"  for  delete.  After  the 
keystroke,  the  <Help  on  Key>  presents  a  window  that  describes  the  proce¬ 
dure  (if  any)  bound  to  the  key  or  keystroke  sequence  that  was  entered. 

<Prompt  For>  <Help>  prompts  for  a  string,  if  the  string  is  the  name  of  a 
command,  then  a  window  explaining  the  command  is  opened.  Otherwise,  a 
list  of  all  commands  containing  the  string  is  displayed.  For  example,  typing 
"delete"  at  the  prompt  displays  a  list  of  all  the  delete  commands,  such  as 
library.delete,  links.delete,  compilation.delete,  ob]ect.delete,  etc.  To  identify  a 
command,  and  thereby  present  a  procedure  description  rather  than  a  list  of 
procedures,  <Prompt  For>  <Help>  requires  only  enough  of  the  command 
name  to  uniquely  identify  it. 

Does  the  program  library  use  a  DIANA  tree  or  any  Intermediate 
representation? 

Ada  objects  are  stored  in  the  Rational  system  only  as  DIANA  trees.  When 
machine  code  is  generated,  it  is  attached  to  the  DIANA  tree  representing  an 
Ada  object. 

If  an  Intermediate  representation  Is  used,  Is  It  Instead  of  or  In  addition 
to  source  code  files? 

The  Rational  Environment  DIANA  trees  are  used  instead  of  source  code  files. 


Characterize  the  Interactivity  of  the  environment  In  terms  of  general 
responsiveness  and  Information  content  of  the  environment’s  feedback. 

The  Rational  Environment  presents  a  user-definable  number  of  windows  on  a 
character-oriented,  66-line  screen.  Each  window  representing  a  library  or 
object  is  labeled  with  a  pathname  of  the  library  or  object.  Windows 
representing  program  output  are  labeled  with  the  name  of  the  program  unit 
generating  them.  When  a  window  is  open  on  a  directory,  a  scrollable  direct¬ 
ory  listing  appears  in  the  window.  The  Rational  Environment  thus  provides 
excellent  feedback  on  where  a  user  is  within  the  hierarchical  directory  struc¬ 
ture  and  what  the  contents  of  any  window  represent.  The  Environment  main¬ 
tains  a  listing  of  windows  that  have  been  opened  during  a  session  and  pro¬ 
vides  commands  to  return  to  any  window  on  the  list.  To  allow  the  user  to 
manage  a  work  session,  windows  can  be  selectively  removed  from  the  list  so 
that  a  long  session  need  not  generate  an  overwhelming  list  of  objects  visited. 
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Execution  of  many  system  commands  generates  a  log  indicating  all  actions 
that  the  system  is  taking  and  any  error  conditions  that  have  occurred.  Log 
messages  generated  by  the  system  are  maintained  for  an  entire  session  and 
are  available  for  review  at  any  time.  This  logging  capability  is  also  provided 
for  the  debugger  so  that  all  commands  issued  and  responses  generated  dur¬ 
ing  a  debugging  session  are  automatically  available  for  review. 

Qualitatively  summarize  the  learning  curve  as  It  applies  to  using  the 
environment  for  programming  In  the  small  activities. 

The  methods  of  navigating,  issuing  commands,  and  generating  programs  in 
the  Rational  Environment  are  sufficiently  different  from  the  methods  of  com¬ 
mand  line  oriented  environments  that  use  the  traditional  edit,  compile,  link 
cycle  that  intensive  initial  training  is  required  to  use  the  Environment  at  all. 
This  training  is  typically  provided  in  a  three  day,  hands-on  seminar  by  the 
staff  of  Rational  and  is  sufficient  to  allow  a  programmer  who  knows  Ada  to 
perform  all  the  kinds  of  work  addressed  by  this  experiment. 

Since  the  user  is  always  in  the  editor,  and  since  Ada  procedures  are  the  only 
means  of  performing  operations  in  the  Environment,  the  Environment  has  a 
highly  consistent  interface.  Thus,  once  the  user  is  over  the  first  major  hurdle 
of  learning  how  to  manipulate  the  Environment,  the  primary  additional  learn¬ 
ing  required  of  users  is  to  assimilate  the  range  of  Ada  procedures  that  the 
Environment  provides. 

When  users  attempt  to  use  a  range  of  features  broader  than  those  covered  in 
initial  training,  the  Environment  will  provide  occasional  minor  but  frustrating 
puzzles  about  how  to  accomplish  specific  tasks  for  some  time.  However,  this 
problem  is  by  no  means  unique  to  the  Rational  Environment. 

Describe  the  user  Interface’s  error  handling,  Including  Its  tolerance  for 
minor  errors  and  clarity  of  error  messages. 

Using  an  invalid  combination  of  keys  for  invoking  a  command  generates  a 
beep.  Since  the  translator  parses  the  command  window,  errors  in  commands 
issued  through  the  command  window  generate  standard  Rational  translator 
error  messages.  The  location  of  the  error  is  underlined,  and  an  explanation 
of  the  error  is  available  with  the  explain  item  key. 

Assess  the  general  helpfulness  of  the  user  Interface  (e.g.,  command 
completion  and  command  history  retrieval  mechanisms). 

The  Rational  Environment  allows  the  contents  of  any  command  window  to  be 
re-executed  or  edited  and  re-executed.  Previous  command  window  contents 
can  be  retrieved  by  placing  the  cursor  in  the  command  window  and  then 
using  the  object  undo  and  object  redo  keys  to  traverse  a  stack  of  command 
window  contents  maintained  by  the  system.  When  a  retrieved  command 
window  is  executed,  the  windows  above  it  on  the  stack  are  discarded.  The 
Environment  will  recognize  the  shortest  command  abbreviation  that  provides 
an  unambiguous  name  for  the  command.  The  complete  key  will  bring  up  a 
named  parameter  association  for  any  command  typed  into  the  command  win¬ 
dow  with  prompts  for  the  parameter  indicating  the  type  of  input  expected. 
Command  parameter  defaults  automatically  appear  in  the  parameter  associ¬ 
ation. 

Assess  the  quality  of  written  documentation.  Pay  particular  attention  to 
support  for  the  translator  and  other  primary  tools. 

Rational  documentation  (see  [6])  is  organized  into  a  User’s  Guide,  the  Basic 
Operations  Manual,  the  Reference  Summary,  and  a  series  of  1 1  reference 
volumes  describing  all  the  procedures  in  the  Environment. 
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The  User's  Guide  contains  material  on  becoming  familiar  with  the  terminal, 
editing  text  files,  and  developing  simple  Ada  programs. 

The  Basic  Operations  Manual  summarizes  the  material  covered  in  Rational 
training  and  is  an  easy  to  use  and  concise  guide  to  how  to  perform  the  basic 
Environment  operations  for  those  who  have  had  Rational  training. 

The  remainder  of  the  documentation  is  reference  material  describing  the  pro¬ 
cedures  and  parameter  types  comprising  the  Environment.  Within  each 
package,  procedures  and  parameter  type  desaiptions  are  listed  in  alphabetic 
order.  Packages  are  grouped  into  logical  sections  such  as  work  space  man¬ 
agement,  editing  images,  and  so  forth.  Each  section  contains  a  table  of 
contents  and  an  index.  Many  sections  contain  introductory  material  that 
covers  information  of  a  scope  wider  than  a  package  (such  as  information 
about  wildcards  used  across  the  Environment  procedures). 

Software  engineers  who  had  the  initial  Rational  training,  but  no  experience 
with  the  Rational  Environment,  had  difficulty  using  the  reference  material  to 
solve  some  problems  because  the  material  describes  the  Environment  at  the 
program  interface  level  of  the  procedures  and  parameter  types  in  the 
packages  comprising  the  environment.  The  common  reaction  has  been  "If 
you  already  know  how  to  do  it,  you  can  easily  find  the  references." 

DD52  Describe  the  helpfulness  of  the  online  help  facility,  Including  support 

for  common  activities  (I.e.  translation,  editing  and  creating  executable 
modules). 

The  help  fadlity  is  described  in  the  response  to  DD44. 

DD53  Describe  any  noted  inconsistencies  exhibited  by  the  environment. 

Some  commands  which  require  string  parameters  provide  the  quotes  in  the 
command  window  prompt,  while  others  require  the  user  to  remember  to  type 
the  quote  marks. 

Missing  subunit  bodies  are  not  detected  by  keys  <Code  (All  Worids)>  and 
<Code  (This  Worid)>  bound  to  the  Compilation. Make  command.  However, 
missing  package  bodies  are  detected.  During  system  development  this 
serves  as  a  stubbing  facility.  A  system  with  missing  subunits  may  be  ex¬ 
ecuted,  and  will  execute  unless  a  missing  subunit  is  called.  In  this  case 
execution  will  halt  with  a  Program  Error.  For  later  phases  of  development 
(integration  testing,  product  testing),  missing  subunits  not  discovered  until 
runtime  could  be  a  problem.  Missing  subunits  and  missing  package  bodies 
should  be  treated  identically  by  a  compilation  procedure  which  checks  for 
closure. 

DD54  How  well  does  the  environment  support  the  concept  of  representing 

multiple  views  of  Ada  code? 

See  DD31. 


System  Interface 

DD55  Assess  the  communications  bandwidth  of  the  editor  (e.g.  screen 

oriented  and/or  line  oriented;  supports  multiwindowing). 

The  Rational  editor  is  multiwindowing  and  allows  text  to  be  copied  or  moved 
from  one  window  to  another  using  exactly  the  same  commands  used  to  copy 
or  move  text  within  a  window.  Multiple  objects  can  be  open  at  once,  and 
multiple  windows  can  be  opened  on  an  object  by  copying  an  open  window 
with  management  attributes  and  operations  can  be  associated  the  <Window> 
C  key  combination.  The  editor  offers  syntax  and  semantics  checking  and 
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completion.  Rational  stated  in  a  training  session  that  the  maximum  effective 
baud  rate  of  the  Environment  for  some  operations  is  4800  baud  due  to  the 
speed  of  Rational  terminal  hardware.  Although  powerful,  the  multiple  win¬ 
dows,  command  windows,  and  accompanying  reverse  video  banners  make  a 
cluttered  screen,  and  can  be  confusing  to  the  novice  user. 

DD56  Assess  the  communication  bandwidth  of  the  environment. 

The  Rational  Environment  has  the  capability  of  presenting  large  amounts  of 
information  simultaneously.  The  system  message  window,  the  3  default  user 
windows,  command  windows,  and  reverse  video  window  banners  can  be 
confusing  for  the  novice  system  user.  Learning  to  make  use  of  the  infor¬ 
mation  presented  and  learning  to  tailor  the  windows  contributes  to  the  steep¬ 
ness  of  the  novice  user’s  learning  curve. 

DD57  How  is  the  underlying  OS  file  system  utilized  for  the  implementation  of 

the  environment  database? 

There  is  no  host  OS  underlying  the  Rational  Environment. 

DD58  How  difficult  Is  it  to  use  OS  tools  from  the  environment? 

Since  there  is  no  distinction  between  the  OS  and  the  Rational  Environment, 
this  question  does  not  apply. 


4.5.  Design  and  Development  Analysis 

4.5.1.  Functionality 

Features  of  the  Rational  Environment  allow  the  use  of  Ada  as  a  compilable  design  language. 
The  Environment  does  not  require  that  Ada  constructs  in  a  compilation  unit  be  complete  before 
they  can  be  compiled;  prompts  for  declarations,  expressions,  and  statements  can  be  left  in  an 
Ada  object  that  can  be  compiled  and  run.  Typical  strategies  for  allowing  compilation  of  incom¬ 
plete  designs,  such  as  use  of  a  TBD  package,  are  not  required  in  the  Rational  Environment.  A 
program  unit  containing  prompts  can  even  be  executed,  and  will  only  result  in  a  runtime  Program 
Error  when  incomplete  code  is  encountered. 

The  Rational  Environment  does  not  provide  any  graphical  design  aids  for  code  development. 

Ada  source  is  entered  through  the  Rational  editor.  The  editor  is  unusually  powerful,  providing 
template  generation,  syntactic  completion  of  Ada  constructs,  semantic  templates  for  subprogram 
calls  (by  generating  a  named  parameter  association),  and  interactive,  incremental  syntax  and 
semantics  checking.  By  using  the  editor’s  error  prevention  and  detection  capabilities  after  enter¬ 
ing  each  statement  or  small  group  of  statements,  entry  of  syntactically  and  semantically  correct 
programs  is  greatly  facilitated. 

The  procedures  for  installing  source  code  in  a  library  and  subsequently  generating  machine  code 
are  all  bound  to  the  keyboard,  so  installation  and  coding  are  one-keystroke  operations.  These 
keystrokes  can  be  used  either  when  the  cursor  is  in  an  image  of  an  Ada  object  or  when  an  Ada 
object  is  selected  in  a  directory  listing.  Since  the  Rational  Environment  links  at  runtime,  users 
need  not  perform  linking  before  running  a  program.  Linking  before  runtime  can  be  forced  by  the 
use  of  pragma  Main  in  a  main  procedure. 
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The  Rational  Environment  will  also  generate  a  stubbed  out  Ada  body  when  provided  with  a  speci¬ 
fication  when  the  <Create  Body>  key  is  used.  Also,  if  no  specification  in  provided  for  a  body,  the 
Rational  Environment  provides  one. 

Program  library  creation  is  fast  and  easy,  requiring  only  the  press  of  a  key  to  invoke  the 
Create_World  or  Create_Directory  procedures.  Specification  of  a  current  library  is  performed 
automatically  by  placing  the  cursor  in  a  library  or  in  the  image  of  an  Ada  object  contained  in  the 
library.  A  program  compiled  into  one  library  can  reference  a  program  compiled  into  another 
library  through  the  use  of  link  commands  that  create  pointers  from  one  library  to  another. 

The  Rational  Environment  library  system  does  not  allow  units  in  the  library  to  become  obsolete.  If 
a  change  is  made  to  a  unit  A  that  would  make  unit  B  obsolete,  unit  B  must  be  made  invisible  to 
other  units  by  demoting  it  to  source  before  unit  A  can  be  changed.  The  Environment  provides 
tools  for  automatically  performing  demotion  that  are  similar  to  the  tools  provided  for  automatically 
performing  promotion.  The  Environment  also  tracks  dependencies  between  libraries  so  that  a 
unit  in  library  A  referenced  by  a  unit  in  library  B  cannot  be  changed  without  first  demoting  the  unit 
in  library  B. 

Environment  switches  can  be  set  to  show  the  state  (source,  installed,  or  coded)  of  all  Ada  units  in 
a  directory.  Program  libraries  can  be  queried  using  the  Ada_Ust  and  Verbose_List  commands 
that  list  units  and  their  state  (source,  installed,  or  coded)  and  the  Xref  command  that  generates 
cross  reference  listings.  The  tool  for  checking  library  completeness  does  not  find  missing  subunit 
bodies. 

All  the  basic  functionality  necessary  to  develop  Ada  code  is  provided  in  a  very  easy  to  use 
environment.  Most  common  operations  are  initiated  with  single  keystrokes.  The  editor  greatly 
facilitates  the  generation  of  syntactically  and  semantically  correct  code. 

4.5.2.  Performance 

A  dedicated  R1000  Model  200-20,  running  the  Delta  0  release  Environment  was  used  when 
timing  was  performed.  Program  library  creation  and  small  compilation  unit  translation  (consisting 
of  package  spedfications  of  less  than  twenty  lines  of  Ada  code)  were  timed.  Executable  module 
creation  takes  place  in  the  Rational  Environment  links  at  runtime.  Linking  can  be  forced  during 
compilation  by  use  of  the  pragma  Main  in  the  main  procedure. 

-  Program  library  creabion: 

Elapsed  bime :  1.73  seconds. 

CPU  bime :  0.70  seconds. 

-  Small  Compilation  Unit  (average  of  installation  and  coding 
of  Vector  Management  specification  and  Matrix  Management 
specification) : 

Elapsed  time:  4.26  seconds. 

CPU  time :  1.93  seconds . 

Program  library  creation  consumed  7426  bytes.  Translating  a  small  unit  resulted  in  the  utilization 


114 


CMU/SEI-88-TR-21 


of  12448  bytes  (average  of  Vector_Management  specification  and  Matrix_Management  specifi¬ 
cation  object  size  and  library  size  increase). 

The  recompilation  characteristics  of  the  Rational  Environment  are  discussed  in  Evaluation  of  the 
Rational  Environment 

4.5.3.  User  Interface 

The  user  of  the  Rational  Environment  is  always  in  the  system  editor  and  therefore  has  an  ex¬ 
tremely  consistent  system  interface.  The  editor  capabilities  available  to  the  user  depend  on  the 
type  of  window  being  edited.  The  most  restrictive  is  the  directory  window  in  which  only  the  editor 
cursor  movement  and  object  selection  and  deletion  operations  are  available.  The  editor  is  at  its 
most  powerful  in  editing  Ada  objects  and  command  windows. 

The  command  language  of  the  Environment  is  Ada.  Ada  procedures  can  be  invoked  either  by 
binding  them  to  the  keyboard  of  the  Rational  Terminal  (which  offers  160  function  key  combina¬ 
tions,  96  of  which  are  prebound  to  commonly  used  Environment  commands)  or  by  entering  them 
in  a  command  window  (aeated  with  the  Create_Command  key)  that  provides  a  declarative  block 
in  which  Ada  procedures  may  execute.  The  full  editor  capacities  including  syntactic  and  semantic 
completion,  and  interactive  syntactic  and  semantic  error  checking  are  available  for  editing  com¬ 
mand  windows.  Since  the  Environment  commands  are  Ada  procedures,  syntactic  or  semantic 
errors  in  entering  a  command  generate  Ada  translator  error  messages. 

The  Rational  Environment  is  a  character-based  windowing  system.  Windows  can  contain  direct¬ 
ories,  Ada  objects,  text  files,  program  output,  etc.  Windows  are  always  labeled  with  a  pathname 
of  a  directory  or  file  or  with  the  name  of  the  program  generating  output  in  the  window.  Proce¬ 
dures  for  navigating  the  directory  structure  are  bound  to  the  keyboard,  so  many  common  move¬ 
ments  (up  a  level,  down  a  level,  home,  from  spec  to  body,  and  from  body  to  spec)  are  available 
with  one  keystroke.  The  system  also  has  a  browsing  capability  that  provides  a  direct  jump  from 
the  place  where  any  type,  subprogram,  or  variable  is  used  to  the  place  where  it  is  declared. 
Markers  can  be  set  in  the  directory  system  to  retrace  a  navigational  path  generated  by  browsing. 

The  Ada  procedures  comprising  the  system  commands  have  been  written  to  use  a  large  set  of 
wildcards,  which  makes  navigation  and  complex  directory  operations  easy.  Command  history  is 
supported  with  the  ability  to  re-execute  command  windows  and  to  retrieve  the  previous  contents 
of  command  windows.  Many  commands  that  change  the  state  of  the  system  (such  as 
Compilation. Promote  or  Library. Copy)  generate  logs,  which  are  retained  for  an  entire  user  ses¬ 
sion.  Since  the  user  interface  consists  entirely  of  Ada  procedures  and  key  bindings,  it  Is  highly 
customizable.  A  problem  in  customizing  the  Environment  is  that  many  system-level  packages, 
such  as  those  that  manipulate  directories,  are  currently  undocumented. 

The  help  system  is  comprehensive  and  convenient  to  use.  Help  on  any  key  or  Environment 
session  switch  is  available  at  a  keystroke,  and  a  facility  for  searching  the  help  files  by  keyword  is 
also  available  with  a  command  procedure.  Keywords  are  components  of  command  names,  not 
command  parameters. 
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The  user  interface  of  the  Rational  Environment  is  very  sophisticated  and  user  friendly.  It  incorpo¬ 
rates  many  features  that  enhance  human  computer  interaction,  including  a  windowing  system, 
easy  navigation  through  the  directory  system,  a  true  system  browsing  capability,  a  powerful  com¬ 
mand  language  (Ada)  and  good  online  help. 

The  learning  curve  for  the  user  interface  is  fairly  steep.  Users  with  three  days  training  required 
about  two  weeks  of  using  the  Environment  before  they  were  completely  comfortable  with  it,  but 
productive  work  was  performed  during  the  acclimatization  period.  After  using  the  Environment  for 
an  extended  period  users  were  reluctant  to  return  to  a  conventional,  command  line  oriented 
environment. 

4.5.4.  System  Interface 

The  Rational  Environment  does  not  run  on  top  of  a  host  operating  system.  It  was  designed  from 
the  ground  up  as  an  Ada  development  environment,  which  has  led  to  the  complete  integration  of 
the  Ada  development  tool  set  with  the  Rational  operating  system. 
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5.  Unit  Testing  and  Debugging  Experiment 


5.1.  Introduction 

The  Unit  Testing  and  Debugging  Experiment  exercises  many  aspects  of  unit  testing  and  debug¬ 
ging.  Provided  are  Ada  units  to  test,  support  routines  for  a  test  harness,  and  test  data  files. 
Experiment  instantiation  calls  for  the  construction  of  a  test  harness,  using  the  capabilities  of  the 
APSE  as  much  as  possible.  It  also  exercises  browsing  facilities,  debugger  capabilities 
(breakpoints,  displaying  variable  values,  tracepoints,  etc.),  static  and  dynamic  analysis  capabil¬ 
ities,  and  regression  testing  capabilities. 

In  the  following  experiment  instantiation,  experiment  steps  are  numbered,  and  substeps  are  let¬ 
tered.  Any  comments  concerning  the  experiment  step  in  the  context  of  the  Rational  Environment 
are  in  regular  type  in  braces  ({ }).  The  instantiation  of  the  experiment  is  provided  as  a  transcript 
of  actual  keypresses.  Comments  as  to  the  correct  context  in  which  to  type  the  indicated  keys, 
and  comments  as  to  what  the  keystroke  will  accomplish  are  indented,  enclosed  in  braces  ({  )), 
printed  in  a  different  typeface.  The  required  keystrokes  are  indented  and  printed  in  typeface, 
and  are  indicated  by  the  letter(s)  appearing  on  the  key  or  its  keymap  designation  appearing  in 
angle  brackets  (<  >).  When  a  command  results  in  information  appearing  in  the  debugger  win¬ 
dow,  the  information  appears  following  the  command,  indented  and  printed  in  a  different 
typeface. 


5.2.  Experiment 

1 .  Build  and  browse  a  test  harness  and  the  supporting  subprograms  to  test  the  func¬ 
tions  which  implement  matrix-vector  multiplication,  vector  multiplication,  and  vector 
inner-product. 

a.  Build  a  test  harness  by  copying  a  subset  of  the  required  files  from  Ada_LIB: 
the  main  procedures,  test_hamess  and  a  supporting  I/O  package, 
testlo_spec  and  testlo_body_exe-etTors.  (Note  that  the  _exe-errors  suf¬ 
fix  indicates  the  presence  of  execution  errors). 

(See  l.b.) 

b.  Translate  the  previously  mentioned  procedure  and  package  into  the  pro¬ 
gram  library  named  TEST_LIB  and  then  attempt  to  create  an  executable 
module.  Take  note  of  the  quality  and  content  of  the  error  messages. 
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{Place  cursor  In  the  Test^Llb  library  and  create 
an  Ada  object . } 

<Object>  I 

{Enter  code  for  procedure  Test^Hamess  and  check 
semantic  correctness.} 

<SexDantlclze> 

{No  errors  found;  promote  to 
coded  state . } 

<Code  Unit> 

{Return  cursor  to  the  enclosing  library. } 

<Enclosing> 

{Enter  in  Testio'spec  and  Testio'body 
in  the  same  manner .  } 

{Rxin  Test^Harness .  } 

<Create  Coinmand> 

{Enter  ’’Test^Harness "  in  the 
command  window. } 

<Proinot> 

{Note  Errors:  procedure  bodies 
Test  Jb4atrix_Vector^Mult , 

Test_Vector_Mult ,  and  Test_Inner_Prod  have 
no  coded  bodies . } 

c.  Retrieve  the  missing  subprograms  from  the  following  files  in  Ada_LIB; 
test_matmult,  test_vecmult,  and  testjnnerprod.  Translate  the  sub¬ 
programs  into  the  program  library  TEST_LIB.  Create  an  executable  mod¬ 
ule. 

{Same  as  1  .b.} 

d.  In  order  to  become  familiar  with  the  test  harness  structure,  browse  its  con¬ 
stituent  subprograms.  Take  note  of  the  various  browsing  methods 
available. 

i.  Browse  the  main  procedure  TEST_HARNESS. 

{Move  cursor  to  Test_Harness' body . } 

<De£lxiltlon> 

(Now  use  the  object  keys  and  arrow  keys  to 
browse  through  the  procedure . } 

ii.  Browse  the  dependent  (called)  procedure 
TEST_MATRIX_VECTOR_MULT. 

{Cursor  Is  sti.ll  In  Test_Harness .  Place 
cursor  on  declaration  of  procedure 
Test_Matrix_Vector_Mult  and  select  it.) 

<Object>  <Left  Arrow> 

<De£lnltlon> 

{Now  browse  as  in  previous  substep. } 

iii.  Browse  the  dependent  package  (WITHed)  package  specification 
TEST  10. 
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{Cursor  is  still  in 

Test_Matrix_Vector_Mult ,  return  cursor 
to  Test_Harness' Body . ) 

<Enclosing> 

{Return  cursor  to  TEST_LIB  library. ) 

<Enclosing> 

{Move  cursor  down  to  Testio' Spec , ) 

<Definition> 

{Now  browse  as  in  previous  substep.} 

iv.  Browse  the  function  body  of  GET_MATRIX. 

{Cursor  is  still  in  Testio 'spec.  Move 
cursor  to  declaration  of  Get_Matrix  and 
select  it . } 

<Object>  <Left  Arrow> 

<Definition> 

{Now  browse  as  in  previous  substep. } 

V.  Browse  the  function  body  of  TEST_VECTOR_MULT, 

{Cursor  is  still  in  Get_Matrix' Body; 
return  cursor  to  Test_Lib.) 

<Enclosing> 

{Move  cursor  to  . Test_yector_Mult . ) 

<Definition> 

{Now  browse  as  in  previous  substep.} 

2.  Debug  the  test  harness  and  associated  supporting  subprograms. 

a.  Create  a  small  test  data  file  using  the  format  described  in  Exhibit  2.1  and 
the  data  (which  abides  by  that  format)  shown  in  Exhibit  2.2. 

{See  2.b.} 

b.  Execute  the  module  using  the  test  data  file  created  above.  This  results  in  a 
CONSTRAINT_ERROR.  (Note:  the  module  reads  from  standard  input  and 
writes  to  standard  output). 

{Return  to  Test_Lib  library.} 

<Enclosing> 

<Enclosing> 

{Run  Test^Hamess  using  the  test  data  from 
exhibit  2.2.} 

<Create  Cotnmand> 

”Test_Harness " 

<Promot> 

{Vector-Multiplication  data  works  correctly. } 

{ Inner -Product  data  works  correctly. } 

{When  running  the  Matrix-Vector  multiplication 
data  a  CONSTRAXNT^^ERROR  is  raised.  Terminate 
the  execution  of  Test  Harness. 

<Job  Kill> 

c.  Determine  the  cause  of  the  CONSTRAINT_ERROR,  modify  the  subprogram 
in  error,  and  continue  to  execute  the  module.  Note  the  level  of  Integration 
between  the  debugger,  the  editor,  and  the  translator. 

i.  Set  breakpoints  upon  the  raising  of  an  exception.  Execute  the  pro¬ 
gram  and  determine  the  problem  statement  and  subprogram. 
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{The  Rational  debugger  automatically  breaks  on  exceptions  unless 
the  debugger  behavior  is  modified  to  propagate  exceptions  with  the 
propagate  procedure.} 

{Return  to  command  window  containing 
"Test_Harness" } 

<Window>  <Up  Arrow> 

{Run  Test_Harness  again  but  tinder  the 
debugger. } 

<Metai>  <Promot> 

<Execute> 

{"Exception  CONSTRAINT_ERROR  (Array  Index)  caught  at 
.TESTlO.GET_MATRIX.3s".  Get_Matrix  procedure  is  displayed  with 
the  line  where  the  exception  occurred  highlighted.) 

ii.  Query  the  values  of  the  variables  num_rows  and  num_cols  and  the 
loop  counters  I  and  j  in  the  procedure  TESTJO.GET_MATRIX.  De¬ 
termine  the  dimensionality  of  the  variable  M.  Conclude  that  the  up¬ 
per  bounds  for  the  loop  counters  for  the  inner  and  outer  loops  must 
be  reversed. 

{There  are  two  ways  to  display  a  value.  The  following  transcript 
uses  both.) 

<Prompt  ror> 

<Put> 

{Command  window  opens;  enter  i 
as  value  of  parameter  "Value"} 

[Value  =>  ""] 

It  ^  It 

<Proniot> 

{Output  to  debugger  execution 
window : } 

4 

{To  display  value  of 

place  cursor  on  **  j  ^  ”  and  select  it . } 

<Object>  <Left  Arrow> 

<Put> 

{Output  to  debugger  execution 
window: } 

1 

{Routine  is  trying  to  read  in  an  4  x  3  matrix  instead  of  a  3  x  4  matrix. 
The  loop  counters  need  to  be  switched.} 

iii.  Modify  GET_MATRIX  so  that  the  upper  bound  for  the  outer  loop  Is 
num_cols  and  the  upper  bound  for  the  inner  loop  is  num_rows. 
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{Cursor  is  already  in  Get  Matrix' body. 

Turn  off  the  selection  of  the  selected 
line . } 

<Itein  Off> 

{Dexnote  the  state  of  Testio'Body  to 
installed. } 

<Install  Unit> 

{Place  cursor  at  the  beginning  of  the  loop 
to  be  changed  and  select  the  loop.} 

<Object>  <Left  Arrow> 

<Edit> 

{An  edit  window  opens  displaying 
loop  code  to  be  edited;  make  change 
and  return  the  corrected  version  to 
the  Testio'Body.} 

<Promot> 

{Return  Testio'Body  to  coded  state.} 

<Promot> 

iv.  Restart  execution  at  the  beginning  of  the  procedure  GET_MATRIX. 
verifying  that  the  error  has  been  corrected. 

{Job  cannot  be  restarted.  It  must  be  terminated  and  a  new  one  must 
be  executed.} 

{Return  to  Test_Lib  library. } 

<Enclosing> 

{ "Test^Harness"  is  still  in  command 
window. } 

<Create  Command> 

{Terminate  the  old  debugger  job  and  begin 
a  new  one . } 

<Me  t  aXP  r  omot  > 

<Execute> 

{Type  input  to  the  executing  program: 

3  4  <Enter> 

1.0  2.0  3.0  4.0  <Enter> 

2.0  4.0  6.0  8.0  <Enter> 

3.0  6.0  9.0  12.0  <Enter> 

4  <Enter> 

1.0  2.0  3.0  4.0  <Enter> 

{Correct  results  appear  in  the 
debugger  execution  window. } 

3.  Perform  a  static  analysis  of  the  module  created  in  above  (Step  1c).  Measure  the 
CPU  and  elapsed  times  for  performing  the  static  analysis. 

a.  Examine  the  overall  quality  of  the  program’s  structure  by: 

i.  Identifying  violations  against  a  prescribed  set  of  programming  guide¬ 
lines. 

ii.  Producing  a  measure  of  each  subprogram’s  complexity  (e.g., 
McCabe’s  Cyclomatic). 

iii.  Identifying  unreachable  statements. 

(No  static  analysis  tools  are  available.} 

b.  Collect  statistics  including  (but  not  limited  to): 
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i.  number  of  executable  lines 

ii.  percent  comment  lines 

Hi.  frequencies  of  statement  types 
{No  supported  statistics  tools  are  available.} 

4.  Create  a  library  of  test  data  using  the  specified  test  data  files  residing  in  Ada_UB 
as  necessary. 

a.  Create  a  test  data  file  to  test  the  "normal"  functionality  of  matrix-vector  multi¬ 
plication  including  the  following  cases  (use  test_input_nonnal  in 
Ada_UB): 

{Return  to  Test_Lib  library. } 

<Window>  <Up  ArroK> 

<Window>  <Up  Arrow> 

<Create  Text> 

{A  comnand  window  opens;  supply 
"Test_Xnput_Nonnal  as  the  value  o£ 
parameter  "File_Naina .  " } 

[rile_Name  ■>  ""] 

" Te  s t_Input_No  rma 1 " 

<Promot> 

{Test_Input  Normal  window  opens, 
enter  data;  when  finished, 
commit  the  data  to  dish. } 

<Promot> 

b.  Create  a  test  data  file  to  test  the  following  boundary  cases  (use 
testJnput_boundary  in  Ada_UB): 

(Same  as  above.} 

c.  Create  a  test  data  file  to  structurally  test  (I.e.,  test  subprogram  control  flows) 
the  subprograms  implementing  matrix-vector  multiplication,  vector  multipli¬ 
cation,  and  inner  product  (use  testjnput_structure  in  Ada_UB).  (Note 
that  the  MATRIX_MANAGEMENT  and  VECTOR_MANAGEMENT 
packages  are  included  in  Appendix  6.B.) 

(Same  as  above.} 

d.  Create  a  test  data  file  to  stress  test  the  three  subprograms  using  data  with 
combinations  of  large  and  small  numbers  (use  test_lnput_str©ss  In 
Ada_UB). 

(Same  as  above.} 

5.  Perfomn  the  initial  baseline  test  of  the  three  mathematical  functions:  matrix-vector 
multiplication,  vector  multiplication  and  inner  product. 

a.  Create  a  file  containing  the  expected  output  when  using  the  files  previously 
created  in  the  preceding  step.  (Use  test_output_expected  from  Ada_LIB.) 

(Create  file  in  the  same  manner  as  in  4.a.} 

b.  Execute  the  module  using  the  test  input  data  and  create  a  file  containing  the 
actual  test  output. 

(In  order  to  have  the  Test_Hamess  input  be  a  given  text  file  and  the  output 
be  sent  to  a  text  file,  Test_Hamess  must  be  run  by  using  the  command 
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"!Commands.Program.Run_Job."  The  command  Run_Job  allows 
Test^lnput"  specified  as  the  input  filename  and  Test_Output_Actuar  to  be 
specified  as  the  output  filename.} 

{Go  to  Test_Lib} 

<Create  Coxnniand> 

’Tile^Utilities  .Append'^ 

<Complt> 

(Source  =>  "Test_Input_Normal" , 

Target  =>  "Test^Input”) ; 

<Promot> 

{Repeat  using  Test^Input^Boundary, 

Te  s  t^I  nput^S  t  ruct  ur  e ,  and 
Test^Input^Stress  as  the  source  file.} 

<Create  Coxnmand> 

"  P  r  ogr  am ,  Run^Job  " 

<Complt> 

(S  =>  "Test^Harness" , 

Debug  »>  False ^ 

Context  => 

After  =>  0.0, 

Options  =>  "Input  :=  Test_Input; 

Output  : =  Test jOutput_Actual " , 

Response  =>  "<PROFILE>" ) ; 

<Proinot> 

c.  Compare  the  actual  output  to  the  expected  output. 

<Create  ConTmand> 

"File^Utilities .Difference " 

<Coinplt> 

(File_l  =>  "Test_Output_Expected, 

File_2  =>  "TestjOutput_Actual" , 

Result  => 

Coo^ressed^Output  »>  False, 

Subobjects  =>  False) ; 

<Proinot> 

{The  only  significant  difference  was  in  the  result  for  the  first  case  in 
Test_lnput_Stress.} 

{Expected} 

Numeric  Error  Raised 
{Actual} 

--  input  matrix 

l.OOE+00  2.00E+20  3.00E+40  4.00E+60  5.00E+80  6.00E+100 
l.OOE+00  2.00E+00  3.00E+00  4.00E+00  5.00E+00  6.00E+00 
--  input  vector 

l.OOE+01  2.00E+01  3.00E+01  4.00E+01  5.00E+01  6.00E+01 
—  result  vector 
3.60E+102  9.10E+02 

(The  actual  output  does  represent  the  correct  answer.} 

6.  Perform  a  dynamic  analysis  of  the  module.  Measure  the  CPU  and  elapsed  time  for 
performing  the  analysis. 

a.  Collect  performance  statistics,  including  CPU  time  for  the  currently  imple¬ 
mented  subprograms  which  perform  matrix,  vector  arithmetic. 
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{No  performance  analysis  tools  are  available.} 

b.  Perform  a  test  data  coverage  analysis,  and  identify  sections  of  code  that  are 
not  executed  when  using  the  test  input  data. 

(No  coverage  analysis  tools  are  available.} 

c.  Collect  general  statistics,  including  the  number  of  conditional  and  uncondi¬ 
tional  branches  traversed  and  the  number  of  times  each  subprogram  was 
executed. 

(No  general  statistics  tools  are  available.} 

7.  Create  a  variation  of  matrix-vector  multiplication  using  a  parallel  algorithm. 

a.  Substitute  for  the  current  implementation  of  matrix-vector  multiplication  the 
new  implementation  retrieved  from  parallel_matmult  in  Ada_LIB. 

(Cursor  Is  In  Test_Llb  library; 
go  to  Project_Lib  library. } 

<Encloslng> 

(Place  cursor  on  Matrlx_Managezaent' Body 
and  select  It . } 

<Object>  <Left  Arrow> 

(Try  to  edit  Matrlx^Managexnent '  Body .  } 

<Edlt> 

(Edit  not  allowed;  note  message  In  message 
window  that  Get_Col'Body  and  Get_Row'Body 
would  be  obsolete . ) 

(Go  to  Pro ject_Llb. } 

<Window>  <Down  Arrow> 

(Place  cursor  on  Mat rlx^Manageme nt ' Body 
and  select  It . } 

<Object>  <Left  Arrow> 

<Dncode  (This  World) > 

(Open  window  on  Matrix  Management '  Body .  } 

<De£lnltlon> 

<Edlt> 

(Enter  code  for  Parallel_Matmult . } 

b.  Define  a  task  type  as  follows  in  the  declarative  part  of  the  package  body  of 

MATRIX_MANAGEMENT: 

task  type  ROW^PRODUCT  Is 

entry  SEND_VECTORS  (Row,  Col  :  in  VECTOR) ; 
entry  RETRIEVE_PRODUCT  (P  :  out  FLOAT)  ; 
end  ROW_PRODUCT; 

task  body  ROW^PRODUCT  Is  separate; 

c.  Create  the  task  body  for  ROW_PRODUCT  by  copying  it  from 
row_product_exe-errors  in  Ada_UB. 
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{Enter  code  for  Row^^Product '  body .  Place 
cursor  on  first  line  of  its  declaration  and 
select  the  declaration.} 

<Object>  <Left  Arrow> 

<Create  Coxn[iiand> 

{Command  window  opens;  enter:} 

'*Ma}ce_Separate  ” 

<Proinot> 

{Commit  data  to  disk.} 

<Enter> 

d.  Create  a  new  module  employing  the  parallel  implementation. 

{Go  back  to  Matrix  Management ' Body . } 

<Enclos ing> 

{Go  back  to  Pro ject_Lib . } 

<Enclo8ing> 

{Place  cursor  on  Matrix_Managextient '  Body 
and  select  it . } 

<Object>  <Left  Arrow> 

<Code  (This  World} > 

{Get^Col,  Get_Row,  Row_Product,  and 
Matrix_Management  go  from  Source  (S} 
to  Coded  (C)  state.} 

8.  Regression  test  the  new  module  and  discover  that  the  output  differs  from  the  initial 
baseline  test  output  created  when  using  the  sequential  algorithm.  Discover  that  the 
new  parallel  algorithm  yields  different  answers  and  also  results  in  a  deadlock  situa¬ 
tion. 

{Testing  is  done  manually.  The  answers  to  the  Matrix_Vector  multiplication  tests 
differ.  The  first  case  from  Test_lnput_Structure  results  in  a  deadlock  situation.) 

9.  Debug  the  parallel  Implementation  of  matrix-vector  multiplication. 

a.  Set  breakpoints  in  GET^MATRIX  after  every  iteration  of  the  outer  loop. 

{Go  to  Tast^Lib.} 

<Craate  Consiiand> 

"Test_Harnass" 

{ Rxin  with  the  debugger .  } 

<Met  aXP  romot  > 

<Create  Coinmand> 

"Debug.  Take__Histoi:y" 

<P romot > 

{Activate  history  recording  in  order  to 
do  a  Show  (histories)  and  History^Display 
later  on  in  the  script.} 

{Go  to  Test_Lib} 

<Window>  <Up  Arrow> 

<Window>  <Up  Arrow> 

{Place  cursor  on  Test_Io' body } 

<Definition> 

{Place  cursor  at  beginning  of  the  inner  loop 
in  Get_^trix'  body  and  select  it .  } 

<Object>  <Left  Arrow> 

{Set  breakpoint.} 

<Break> 
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b.  Set  a  tracepoint  after  every  iteration  of  the  outer  loop  for  the  loop  counter  i 
and  for  the  Ith  row  of  the  matrix  M. 

{The  Rational  Environment  does  not  have  tracepoints  in  the  VAXA/MS 
sense.  Therefore,  the  breakpoints  which  were  activated  in  9.a.  will  be  used 
along  with  the  proper  Debug  Put  procedures.} 

c.  Set  a  tracepoint  for  the  v  in  GET_VECTOR  for  every  time  v  changes  value. 

{Cursor  is  still  in  Test_Io .body; 
move  cursor  to  statement  in  loop  in 
Get_Vector'body  and  select  it.} 

<Object>  <Left  Arrow> 

{ Set  breakpoint . } 

<Break> 

d.  Compare  the  values  of  M  in  GET_MATRIX  and  v  in  GET_VECTOR  with  the 
respective  values  in  the  test  input  file  and  conclude  that  the  data  is  being 
read  properly. 
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<Execute> 

•’  Mat  r  ix^Ve  ct  or JMult " 

<Promot> 

Testing  Matrix-Vector  Multiplication 

II 2  3  ” 

<Promot> 

{Break  at  Get^Matrix . 2s } 

<Run> 

<Rvin> 

”1.0  2.0  3.0” 

<Promot> 

{Break  at  Get .Matrix . 3s } 

<Proinpt  For> 

<Put> 

[Put  =>  ””] 

II  ^  II 
1 

<Promot> 

<Run> 

<Run> 

<Run> 

{Read  in  first  row  of  the  matrix. } 
{Display  values  read  in  for  the  matrix. } 
<Pron^t  For> 

<Put> 

[Put  =>  ""] 

"M(l,  1)  ” 

<Promot> 
l.OOe+00 
<Prompt  For> 

<Put> 

[Put  => 

'’M(l,2)  ” 

<Proinot> 

2.00e+00 
<Prompt  For> 

<Put> 

[Put  =>  ””] 

"M(l,3)  ” 

<Promot> 

3.00e+00 

<Execute> 

”4.0  5.0  6.0" 

<Promot> 

II 2 

<Promot> 

<Run> 

”10.0  20.0  30.0” 

<Promot> 
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{ Break  at  Get^Vector -  2s } 

<Proxnpt  For> 

<Put> 

[Put  =>  ””] 

*1  ^  H 

<Proxnot> 

2 

<Run> 

{Display  values  read  in  for  the  vector. } 

<Prompt  For> 

<Put> 

[Put  => 

”v(l)  ” 

<Proxnot> 

1. OOe+01 
<Run> 

{ Break  at  Get_Vector . 2s ) 

<Proxnpt  For> 

<Put> 

[Put  => 

”v(2)  ” 

<Promot> 

2.00e+01 

e.  Set  a  breakpoint  upon  rendezvous  with 
PARALLEL_ROW_PROD.SEND_VECTORS. 

{Due  to  naming  conventions  on  the  Rational  Environment, 
"ParalleLRow_Prod.Send_Vectors"  is  listed  as 

"Matrix_Management.Row_Product."} 

{Go  to  Matrix_Manageznent  .Row_Product, 
place  cursor  on  rendezvous  statement,  and 
select  it . } 

<Object>  <Left  Arrow> 

{ Set  breakpoint . } 

<Break> 

f.  Display  task  status,  the  current  breakpoints  and  tracepoints,  the  program 
stack  and  history. 

<Task  Display> 

Task__Display  ( "  "  ,  All_Tasks )  ; 

Job:  232  Root  task:  #B54E8 

ROOT_TASK,  #B54E8 :  Step  complete  at 

.TEST  HARNESS. TEST  MATRIX  VECTOR  MaLT.9s  [Pri  =  1} 


<Show  Breaks> 

Show  (BREAKPOINTS>; 

Active  Permanent  Break  1  at 

Active  Perxnanent  Break  2  at 

Active  Permanent  Break  3  at 


, TEST_IO . GET_MATRIX , 2S 
[any  task] 
. TEST_IO . GET_VECTOR . 2S 
[any  task] 


.MATRIX  MANAGEMENT . ROW  PRODUCT,  IS 


[any  task] 


{Go  to  debugger  window.} 
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<Debugger  Window> 

<Create  Coxnmanci> 

{Enter  in  command  window;} 

"Show  (Traces) " 

<Promot> 

Show  (TRACES) ; 

No  tasks  are  tracing  calls. 

No  tasks  are  tracing  statements. 

No  tasks  are  tracing  exceptions . 

<Stack> 

Stack  ("",  0,  0)  ; 

Stack  of  task  RCXDT^TASK,  #B54E8; 

_1 :  TEST_MATRIX_VECTOR_MULT  .  9s 

_2:  TEST_HARNESS.2s.3s 

_3:  TEST_HARNESS.2s 

;  commander ocedure .  Is 

_5 :  coxnmand_procedure  [library  elaboration  block] 

<Create  Coxnznand> 

{Enter  in  command  window:} 

"Show  (Histories) " 

<Promot> 

Show  (Histories) ; 

History  of  Calls  is  being  recorded  for: 

all  tasks  at  all  locations 
History  of  Statements  is  being  recorded  for: 

all  tasks  at  all  locations 
History  of  Exceptions  is  being  recorded  for: 
all  tasks  at  all  locations 


<Create  Coxnmand> 

{Enter  in  command  window:} 
" Hist ory_Display " 

<Promot> 


History_Display  (0,  0,  ""); 

History  of  statements  executed  by  all  tasks 

(oldest. .newest) 


Timestamp  Depth 
251269226399  6 

251276928611  5 

+  336  5 

+  996  5 

+  1265  5 

+  1383  6 

+  1771  6 

251370692649  5 

+  487  5 


Location  and  Task 
,  TEST_IO .  GET_VECTOR_DIM.  Is 

[ROOT_TASK,  #B54E8] 

. TEST_HARNESS . TEST_MATRIX_VECTOR_MULT . 6s 

_ 7s 

....  8s 

. TEST_IO . GET_VECTOR . 1 s 
....  Is 
_ 2s 

.  TEST_HARNESS  .  TEST_MATRIX_VECTOR_MULT  .  8s 
_ 9s 


g.  Display  the  values  for  row_vector.all  and  col_vector.all  in 
PARALLEL_ROW_PROD.SEND_VECTORS  and  notice  that  they  are  equal 
at  each  rendezvous. 
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<Run> 

<Execute> 

<Run> 

<Riin> 

<Prompt  For> 

<Put> 

[Put  =>  »»"] 

" Col_Vect or . all ” 

[1..3] 

[1  =>  4.00E+00  . . . 

2  =>  5.00E+00  . . . 

3  =>  6.00E+00  . . . ] 

<Pro*npt  For> 

<Put> 

[Put  =>  ""] 

"Row_Vector . all " 

[1..3] 

[1  =>  4.00E+00  . . . 

2  =>  5.00E+00  . . . 

3  =>  6.00E+00  . . . ] 

h.  Modify  the  line  in  PARALLEL_ROW_PROD.SEND_VECTORS  which  as¬ 
signs  col_vector  to  be 

Col_Vector  :=  New  Vector' (Col) ; 

{Go  to  Parallel_Row_Prod.  Send__yectors . 

<Item  Off> 

{Move  cursor  to  and  select  statement 
to  be  changed. } 

<Object>  <Le£t  Arrow> 

<Edit> 

{Edit  window  opens  with  selected 
statement  In  It;  make  change  In  edit 
window  and  place  change  back  In  body. } 

<Promot> 

{Place  body  back  In  coded  state.) 

<Promot> 

i.  Set  a  breakpoint  at  the  entry  and  exit  point  for  the  matrix-vector  multipli¬ 
cation  (MVM)  function. 

{Due  to  a  problem  in  the  debugger,  was  unable  to  set  a  breakpoint  in  the 
overloaded  function  Overload  resolution  of  infix  operators  was  not  work¬ 
ing.  To  solve  the  problem,  had  to  change  all  occurrences  of  to  the  proce¬ 
dure  call  "Times(U,  V)."  The  transcript  of  steps  following  still  applies,  even 
with  the  change.} 
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{Go  to  Matrix_Management '  body,  move 
cursor  to  the  first  declaration  statement, 
and  select  it . } 

<Object>  <Left  Axrow> 

{ Set  breakpoint . } 

<Break> 

(Move  cursor  to  the  last  statement  in 
the  procedure  and  select  it.} 

<Object>  <Left  Arrow> 

(Set  breakpoint.} 

<Break> 

j.  Jump  to  the  entry  point  of  the  MVM  function. 

{In  order  to  make  use  of  changes  made  above,  current  job  is  terminated  and 
a  new  one  is  started.} 

(Put  job  into  the  background. } 

<Control>  <G> 

<Job  Kill> 

(Go  to  Test^Lib.} 

<Create  Command> 

"Test  Harness" 

<Met  aXP  r  omot  > 

(To  re-use  previous  jobs'  breakpoints, 
must  reactivate  them. } 

<Activate> 

{ Enter  data . } 

k.  Set  a  tracepoint  for  the  vector  variable  product  upon  exiting  the  MVM  func¬ 
tion. 


(Continue  through  the  breakpoints 
to  the  second  breakpoint,  which  is 
just  before  the  return  statement 
in  the  MVM  function.  } 

<Execute> 

<Prompt  For> 

<Put> 

[Value  =>  ""] 

"Product " 

1.4E+01 

I.  Using  a  test  case  that  previously  (before  the  parallel  algorithm  was 
implemented)  resulted  in  the  raising  of  an  ERROR  condition  in 
TEST_HARNESS,  determine  where  the  deadlock  occurs.  Assess  the  level 
of  difficulty  in  determining  the  cause  of  the  deadlock,  (Note  that  the  ERROR 
condition  is  Initially  caused  by  the  raising  of  DIMENSION_ERROR  In  the 
MVM  function.) 

(The  deadlock  occurs  as  a  result  of  the  Dimension_Error  exception  being 
raised.  The  function  attempts  to  end  but  a  Debug  Task  Display  shows 
that  it  has  children  tasks  running  and  waiting  at  an  accept  for  an  entry  call. 
Since  a  parent  cannot  end  before  its  children  end,  the  program  becomes 
deadlocked.  Upon  examination  of  the  situation  the  reason  for  the  deadlock 
was  fairly  obvious.) 
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<Meta>  <Promot> 

<Execute> 

5  3 

1.0  2.0  3.0 
1.0  2.0  3.0 
1.0  2.0  3.0 
1.0  2.0  3.0 
1.0  2.0  3.0 
5 

10.0  20.0  30.0  40.0  50.0 

Exception  Vector_Management .  Diiaenslon^Error 
caught  at  .Matrix^Management .times' N (2) .2s 
<Task  Display> 

#  4  4  4FB  ( >Mat r Ix^Management .  Row_P r oduct )  :  Running , 
waiting  at  accept  for  entry  call  [Prl  =:  1] 

m.  Use  rowjroduct  from  Ada_UB  to  create  a  new  module  that  no  longer 
deadlocks.  (Note  that  this  new  version  of  ROW_PRODUCT  includes  a  set 
statement  with  a  terminate  alternative.) 

{ Define  Mat rlx^Managexnent '  body .  Row_Pr oduct .  } 

<Edit> 

(Change  to  coded  state.} 

<Code  Unit> 

{ Go  to  Matrlx_Manageznent '  body . } 

<Enclo8 lng> 

(Go  to  Pro ject_Lib.  } 

<Encloslng> 

1 0.  Regression  test  the  corrected  module. 

(Place  cursor  on  Test^Llb. } 

<Deflnltlon> 

<Create  Coiniaand> 

”Test_Hamess  ” 

<Prooaot> 

{Test  is  done  manually.  It  works.} 


5.3.  Functionality  Checklist 


PRIMARY  ACTIVITIES 


Activity 

Step  # 

Supported 

(Y/N) 

Observations 

Unit  testing 

Create  and  debug  test  harness . 

.  1,2 

No 

Create  test  input  data  for 

functional  testing . 

. .  4a 

No 

boundary  case  testing . 

No 

structural  testing . 

No 

stress  testing . 

.  4d 

No 

Perform  initial  test 

create  expected  output  data . 

No 

Done  manually. 

produce  actual  output  data . 

.  5b 

Yes 
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compare  actual  and  expected  data 


Done  manually. 


5c 


Perform  dynamic  analysis 

measure  execution  time  by  subprogram .  6a 

perform  test  data  coverage  analysis .  6b 

identify  code  not  executed .  6b 

measure  statement  execution  frequency .  6c 

Perform  regression  testing .  8,1 0 

Debugging 

Set/reset  breakpoints  on  program  unit 

entry/exit .  9i 

exception .  2c 

statement .  2c 

nth  iteration  of  a  loop .  9a 

variable  changing  value .  gen 

variable  taking  on  a  specified  value .  gen 

rendezvous .  9e 

Control  execution  path 

jump  n  statements .  gen 

enter  a  specified  subprogram .  2c, 9i 

exit  the  current  subprogram .  gen 

Query  program  state 

display  source  code .  2c 

display  breakpoints .  9f 

display  tracepoints .  9f 

display  stack .  9f 

display  history .  9f 

display  task  status . . .  9f 

Modify  program  state 

modify  variable  values .  2c 

add,  modify  and  delete  code .  2c,9h 


No 


No 

No 

No 

No 

No 


Yes 

Yes 

Yes 

Yes 

No 

No 

Yes 


Yes 

Yes 

Yes 


Yes 

Yes 

Yes 

Yes 

Yes 

Yes 


Yes 

No  Changes  can  be  made  but  they  will  not 
affect  current  debugging  session. 


SECONDARY  ACTIVITIES 


Unit  testing 


Perform  static  analysis 


check  against  prog,  guidelines . 

.  3 

No 

measure  subprogram's  complexity . 

3 

No 

identify  unreachable  statements . 

3 

No 

Debugging 

Set/reset  tracepoints  on 
program  unit  entry/exit . . 

.  gen 

Yes 

exception . . 

.  2c 

Yes 

statement . . 

.  9b 

Yes 

nth  iteration  of  a  loop . . 

.  9b 

No 

variable  changing  value . . 

.  gen 

No 

variable  taking  on  a  specified  value . . 

.  gen 

No 

rendezvous . 

.  gen 

Yes 
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5.4.  Experiment  Answers 


Question 

TD1 

TD2 

TD3 


TD4 


TD5 


TD6 


TD7 

TD8 


Response 

Describe  the  mechanics  of  using  the  environment  for  creating  and  de¬ 
bugging  the  test  harness. 

There  are  no  tools  for  generating  a  test  harness. 

Describe  those  aspects  of  test  harness  generation  which  are 
automated. 

See  TD1. 

How  easy/difficult  Is  It  to  use  the  environment  for  creating  and  debug¬ 
ging  a  test  harness? 

The  same  level  of  difficulty  as  developing  any  Ada  program  in  the  Rational 
Environment.  Procedures  to  execute  a  program  (Program. Run  and 
Program.Run_Job),  as  well  as  routines  to  compare  output  with  expected  out¬ 
put  (File_Utilities.Difference),  are  available  to  be  used  in  a  test  harness. 

Does  the  debugger  operate  In  a  screen  mode  and/or  command  line 
mode? 

The  debugger  is  always  operating  in  a  screen  mode.  Commands  are  entered 
either  through  use  of  keys  to  which  debugger  procedures  are  bound  or 
through  a  command  window  that  can  be  attached  to  any  window  on  the 
screen.  This  treatment  of  the  command  interface  is  completely  consistent 
with  any  other  use  of  the  Rational  Environment. 

is  a  multi-windowing  capability  available  from  within  the  debugger? 

The  Rational  debugger  only  operates  In  a  multi-window  mode.  It  uses  a 
debugger  window  in  which  output  of  debugger  commands  is  displayed  and  a 
source  code  window  that  displays  source  code  when  either  single  stepping  or 
hitting  break  points.  Commands  and  their  parameters  are  echoed  to  the 
debugger  window  so  that  the  window  forms  a  complete  log  of  a  debugging 
session.  During  single  stepping  or  when  hitting  breakpoints,  the  debugger 
highlights  the  line  about  to  executed  in  the  source  code  window.  If  the 
program  being  debugged  generates  readable  output,  the  output  appears  in  a 
third  window. 

Describe  the  mechanics  of  accessing  test  data  from  within  the 
debugger. 

The  mechanics  of  accessing  test  data  from  within  the  debugger  are  the  same 
as  they  are  outside  the  debugger  since  it  is  possible  to  move  freely  in  and  out 
of  the  debugger  during  a  debugging  session.  The  user  opens  a  window 
containing  the  contents  of  the  test  data  file. 

How  easy/difficuit  is  it  to  access  test  data  from  within  the  debugger? 
Very  easy.  See  TD6. 

Describe  the  mechanics  of  setting  and  resetting  breakpoints. 

There  are  two  ways  to  set  breakpoints.  The  simplest  method  is  to  select  a 
statement  in  the  source  code  window  and  then  press  the  <Break>  key.  The 
second  method  is  for  the  user  to  be  prompted  for  the  Debug. Break  procedure 
in  a  command  window.  When  executed  from  a  command  window,  the  state¬ 
ment  on  which  the  break  is  to  be  set  is  passed  to  the  Debug. Break  either  by 
selecting  it  (as  in  the  simple  method)  or  by  passing  the  name  of  the  state¬ 
ment  at  which  a  breakpoint  is  to  be  set  as  a  parameter.  Statement  names 
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TD9 

TD10 

TD11 

TD12 


TD13 

TD14 


are  the  name  of  the  procedure  in  which  the  statement  occurs  concatenated 
with  and  a  line  number.  The  line  number  may  be  determined  with  the 
Debug.Display  procedure.  Declarations  and  statements  are  numbered 
separately.  When  Debug. Break  is  executed  from  a  command  window,  three 
parameters  may  be  set:  Stack_Frame,  Count,  and  ln_Task.  Stack_Frame 
provides  a  means  for  specifying  a  frame  in  which  to  set  a  breakpoint.  Count 
specifies  the  number  of  times  the  statement  is  to  be  executed  before  a  break 
occurs.  ln_Task  specifies  that  a  break  is  to  occur  only  if  the  code  is  executed 
by  a  particular  task. 

Once  the  debugger  Is  invoked  it  remains  active  until  the  user  logs  off.  This 
allows  the  debugger  to  remember  breakpoints  that  have  been  set  in  a  pro¬ 
gram.  If  a  program  is  re-executed,  the  command  "Activate  (0)"  reactivates  all 
breakpoints  previously  set  in  the  program.  Specific  breakpoints  can  be  reac¬ 
tivated  by  passing  in  the  break  point  identification  number. 

How  easy/difficuit  is  it  to  set  and  reset  breakpoints? 

Very  easy  using  the  select  a  statement  and  push  a  key  method. 

Are  graphical  tools  available  from  within  the  debugger  to  convey  the 
program  state? 

No. 

Describe  the  differences  (if  any)  between  invoking  a  module  and  Invok¬ 
ing  the  module  for  debugging.  A  module  can  be  executed  either  by  select¬ 
ing  it  in  a  directory  and  pressing  the  promote  key  or  by  opening  a  command 
window,  typing  in  the  module  name,  and  pressing  the  promote  key.  Similarly, 
a  module  can  be  Invoked  for  debugging  by  selecting  it  in  a  directory  and 
pressing  the  meta  key,  followed  by  the  promote  key,  or  by  opening  a  com¬ 
mand  window,  typing  in  the  module  name,  and  pressing  the  meta  key  fol¬ 
lowed  by  the  promote  key. 

Describe  the  mechanics  of  controlling  the  execution  path. 

Two  debugger  procedures  that  control  execution  are  bound  to  the  keyboard. 
Debug. Execute  causes  the  program  to  run  until  a  breakpoint  is  hit. 
Debug.Run  steps  through  a  program  until  a  specified  event  has  taken  place. 
A  parameter  to  Debug.Run  defines  the  event.  Debug.Run  is  bound  to  the 
keyboard  with  two  default  events,  Local_Statement  and  Statement. 
Local_Statement  causes  Debug.Run  to  step  to  the  next  statement  in  a  sub¬ 
program  without  descending  into  the  code  of  subprogram  calls.  Statement 
causes  Debug.Run  to  step  through  a  program  descending  into  the  code  of 
subprogram  calls.  Additional  parameters  to  Debug.Run  allow  stopping  at  the 
point  of  entry  to  procedures,  just  prior  to  returning  from  a  subprogram,  just 
after  returning  from  a  subprogram,  and  at  the  beginning  and  end  of  rendez¬ 
vous. 

For  concurrent  programs  the  debugger  offers  a  rich  set  of  commands  to  stop 
and  start  the  execution  of  individual  tasks  or  groups  of  tasks. 

Describe  the  mechanics  of  Invoking  the  debugger.  Does  the  program 
have  to  be  retranslated? 

The  mechanics  of  invoking  the  debugger  are  explained  in  TD1 1 .  Programs 
do  not  have  to  be  retranslated  before  they  can  be  run  under  the  debugger. 

Describe  the  mechanics  of  modifying  the  program  state. 

The  value  of  a  variable  in  a  program  can  be  changed  with  the  procedure 
Debug. Modify.  The  variable  to  be  modified  can  be  indicated  either  by  select- 
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ing  it  or  by  providing  its  pathname.  The  components  of  records  and  arrays 
must  be  modified  individually:  there  is  no  provision  for  modifying  them  with 
aggregates.  The  debugger  does  not  allow  the  following  objects  to  be  modi¬ 
fied: 


•  access  types  (can  be  modified  only  to  the  null  value) 

•  variables  of  task  types 

•  constants 

•  in  parameters 

•  discriminants  of  variant  records 

•  for  loop  iteration  variables 

Code  can  be  modified  at  any  point  from  within  the  debugger  in  the  same 
manner  that  it  is  modified  from  outside  the  debugger:  Define  the  module  to 
be  modified,  put  it  in  the  installed  or  source  state  and  edit  Because  the 
source  code  and  the  executable  module  are  one  object  in  the  Rational  Envi¬ 
ronment,  this  action  causes  the  debugger  to  lose  track  of  Its  location  in  the 
code.  The  statement  to  be  executed  ceeises  to  be  highlighted  in  the  source 
code  window,  the  debug  stack  command  displays  the  message  "Program 
has  been  recompiled  since  debugger  started,"  and  variable  values  can  no 
longer  be  displayed.  Although  an  edited  program  will  continue  to  execute, 
debugging  must  be  restarted  in  order  for  the  debugger  to  generate  useful 
information. 

Describe  the  mechanics  of  querying  the  program  state. 

Display  source  code: 

Source  code  being  single-stepped,  source  code  around  a  breakpoint,  and 
statements  that  raise  an  exception  are  automatically  displayed  in  the  source 
code  window.  The  procedure  Debug. Display  will  display  source  around  a 
pathname.  However,  the  pathname  must  include  a  declaration  or  statement 
number. 

Display  variable  values: 

Variable  values  are  displayed  by  selecting  the  variable  and  pressing  the 
debug  put  key  or  by  invoking  the  Debug. Put  procedure  from  a  command 
window  and  passing  a  variable  name.  When  Debug. Put  is  invoked  from  a 
command  window,  the  variable  name  is  evaluated  in  a  default  context  which 
is  the  current  scope.  A  separate  procedure  can  reset  the  context  in  which  the 
variable  name  is  evaluated.  Display  of  a  selected  variable  Is  Independent  of 
the  evaluative  context. 

Structured  and  designated  objects  can  be  displayed  by  user-written  proce¬ 
dures  to  improve  the  readability  of  the  output.  This  capacity  is  useful,  for 
example,  when  displaying  a  linked  list. 

Display  breakpoints  and  tracepoints: 

Breakpoints  are  shown  by  pressing  the  Show  Breaks  key.  Tracepoints  are 
shown  by  invoking  Debug. Show  from  a  command  window  and  passing  the 
Debug.Trace  parameter.  Rational  tracepoints  do  not  show  values  of  vari¬ 
ables,  they  print  a  message  when  a  particular  event  occurs  in  a  task. 

Display  stack: 

Press  the  Stack  key. 
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Display  history: 

Invoke  the  Debug.Show  procedure  from  a  command  window  and  pass  the 
Debug. History  parameter.  History  recording  must  be  turned  on  by  the 
Take_History  procedure  before  a  call  of  Debug.Show  with  the  history 
parameter  has  an  effect. 

Display  task  status: 

Press  the  Task  Display  key. 

How  easy/difficult  Is  It  to  control  the  execution  path? 

Very  easy. 

How  easy/difficult  Is  It  to  modify  the  program  state? 

Very  easy. 

How  easy/difficult  Is  It  to  query  the  program  state? 

Very  easy. 

How  effective  Is  the  debugger  In  conveying  the  program  state  at  any 
given  point  (e.g.,  source  code  straddling  the  current  breakpoint,  vari¬ 
able  values  In  the  current  scope,  the  name  of  the  calling  subprogram)? 

The  debugger  can  convey  most  aspects  of  the  program  state.  Below  is  a 
sample  session  with  the  debugger. 

<Execute> 

KxAouttt  C")  ; 

BrMk  1, 

Br«&k  at  aalaotAd  object. 

breakpoint  haa  boon  created  and  aotiTmted: 

XotiTe  Peraenent  Break  3  at  > MATRJX_MBlfkfiglCMrr . msw^PRODOCT .  1 S  [anytaak] 

<Task  Display> 

Taak_Diaplay  C",  ALL_TAB]CB)  ; 

i7ob:  232,  Root  taak:«B54X8 

RDOT^TASIC,  iB54R8:  Step  oo^lete  at 

.TKST_SXRl(XSS.TKST_KXTRJX_VRCTOR_MaLT.9a  [Pri  m  1] 

<Show  Breaks> 

Show  (BRJLkXPOIirrS)  ; 

ActiTe  Permanent  Break  1  at  .TZST_IO .aKT_ICATRZX. 2S  [any  taak] 

XotiTe  Permanent  Break  2  at  .TBST_IO.aZT_VBCTOR.2S  [any  taak] 

XotiTe  Permanent  Break  3  at  .)CXTRZX_KUiauaeMZirr  .R09r_PR0D0CT .  IS  [any  taak] 

<Create  Coinmand> 

*'Show  (Traces) 

<Proxnot> 

Show  (TRACKS)  ; 

Bo  taaka  are  tracing  calla . 

Bo  taaka  are  tracing  atatamenta . 

Bo  taaka  are  tracing  exceptiona . 

<Stack> 

stack  0,  0); 

Staok  of  taak  ROOT_TASK,  iB54K8: 

_1 :  TKST_KATRIX_VBCTOR_KDLT  .  9  a 

_2:  TSST_KARBESS.2a .3a 

^3  :  TZST^KARBKSS . 2a 

:  oomaand_prooedare  .la 

_5 :  ocamiand_j)rooedure  [library  elaboration  block] 
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<Create  Cotnnianci> 

"Show  (Histories) " 

<Proinot> 

Show  (KISTORIXS) ; 

His'tory  of  Calls  is  boing  raoordod  for; 

all  tasks  at  all  locations 
History  of  Statamant s  is  baixtg  raoordad  for: 

all  tasks  at  all  locations 
History  of  Cxoaptions  is  baing  raoordad  for: 
all  tasks  at  all  locations 


<Create  Coxnmand> 

”Histoz:y_Display” 

<Promot> 


Hi story_Di splay  (0,  0, 

History  of  statamants  axacutad  by  all  tasks  ;  (oldast . .nawast) 
Tiaasta^  Daptb  Z«ocation  ax^  Task 

2512  69226399  6  .TE3T_IO.<aKT_VHCTOR_DllC.ls  [ROOT_TA3K,  |B54S8] 

127  6  Is 

251276928611  5  .TKST_BAKHKSS.TZST_XILTRXX_VECTOR_liaz.T.  6s 

+  336  5  .7.  .7s  “ 

+  996  5  8s 

+  1265  6  .THST_IO.aHT_VBCTOR.ls 

+  1383  6  .7.  .Is 

+  1771  6  2s 

251370692649  5  .XXHT  RAMIEH5 . TEST  HXSRXX  VECTOR  HOLT. 8s 


How  integrated  is  the  transistor  and  editor  with  the  debugger? 

The  three  tools  are  basically  standalone  tools.  The  editor  can  be  used  with 
the  debugger  running  in  another  window,  but  if  program  code  is  modified  the 
debugger  will  still  run  the  old  versions  of  the  source  code.  The  old  program 
must  be  terminated  and  a  new  one  invoked  in  order  to  run  the  updated  ver¬ 
sion. 


The  debugger  can  no  longer  report  any  information  about  a  program  unit  that 
has  been  edited  while  it  is  being  debugged.  This  is  due  to  the  fact  that 
source  code  and  object  code  are  contained  in  the  same  Ada  object  in  the 
Rational  Environment.  Editing  an  object  apparently  destroys  some  linkages 
that  allow  the  debugger  to  show  the  source  corresponding  to  the  object  code. 
This  seems  to  be  a  reasonable  limitation. 

The  debugger  is  completely  integrated  with  the  Rational  browsing  capability. 
Selecting  a  variable  and  requesting  a  definition  by  pressing  the  <Definition> 
key  causes  a  window  containing  the  source  code  for  the  definition  of  the 
variable  to  open. 

What  are  the  space  utilization  ramifications  of  instrumenting  code  for 
debugging? 

None. 

Do  the  analysis  tools  present  a  graphical  representation  of  the 
program? 

No  analysis  tools  are  available. 

What  are  the  space  utilization  ramifications  of  instrumenting  code  for 
analysis? 

See  TD22. 


Describe  the  Information  available  from  static  analysis. 
No  supported  static  analysis  tools  are  available. 

Describe  the  mechanics  of  performing  static  analysis. 
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Not  applicable,  see  TD24. 

TD26 

How  easy/difficuit  Is  It  to  perform  static  analysis?: 

Not  applicable,  see  TD24. 

TD27 

What  are  the  CPU  and  clock  times  for  performing  a  static  analysis  of  the 
test_hamess  and  modules  to  be  tested? 

Not  applicable,  see  TD24. 

TD28 

Describe  those  aspects  of  performing  tests  which  are  automated. 

There  are  no  tests  available  which  are  automated. 

TD29 

Describe  the  mechanics  of  using  the  environment  to  create  a  test  plan 
and  test  data. 

Test  data  must  be  created  manually  with  the  editor. 

TD30 

Describe  those  aspects  of  test  data  generation  which  are  automated. 
Test  data  generation  is  not  automated. 

TD31 

How  easy/dIfficuit  is  It  to  use  the  environment  to  create  a  test  plan  and 
test  data? 

See  TD30. 

TD32 

Describe  the  differences  (If  any)  between  invoking  a  module  and  Invok¬ 
ing  the  module  for  unit  testing. 

There  are  no  available  tools  for  unit  testing. 

TD33 

Describe  the  mechanics  of  performing  initial  unit  testing. 

See  TD32. 

TD34 

How  easy/difficult  is  it  to  perform  initial  unit  testing? 

See  TD32. 

TD35 

Describe  the  information  available  from  dynamic  analysis. 

There  are  no  available  tools  for  dynamic  analysis. 

TD36 

Describe  the  mechanics  of  performing  dynamic  analysis. 

See  TD35. 

TD37 

How  easy/difficuit  is  it  to  perform  dynamic  analysis? 

See  TD35. 

TD38 

What  are  the  CPU  and  clock  times  for  performing  a  dynamic  analysis  of 
the  test_harness  and  modules  to  be  tested? 

See  TD35. 

TD39 

Describe  the  mechanics  of  performing  regression  testing. 

There  are  no  available  tools  for  regression  testing. 

TD40 

How  easy/difficuit  Is  It  to  perform  regression  testing? 

See  TD39. 

TD41 

Describe  the  mechanics  of  setting  and  resetting  tracepoints. 

The  tracing  facility  of  the  debugger  causes  a  message  to  be  displayed  each 
time  a  certain  kind  of  event  occurs  in  a  task  for  which  tracing  is  enabled. 
Traces  can  generate  a  message  for  a  statement,  call,  rendezvous,  or  excep¬ 
tion.  They  do  not  provide  values  of  variables.  Tracing  is  enabled  or  disabled 
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by  executing  Debug. Trace  from  a  command  window.  The  parameters  are  On 
(enable/disable  toggle),  Event  (what  is  to  be  traced),  ln_Task  (in  which  tasks 
is  tracing  enabled),  At_Location  (which  specifies  a  scope  within  which  tracing 
is  enabled),  and  Stack_Frame  (which  specifies  the  frame  or  subprogram  to 
perform  tracing.) 

How  easy/difficult  Is  It  to  set  and  reset  tracepoints? 

Very  easy. 

How  accessible  are  environment  tools  from  within  the  debugger? 

All  tools  available  outside  the  debugger  are  also  available  while  using  the 
debugger. 

Assess  the  quality  of  written  documentation.  Pay  particular  attention  to 
support  for  the  debugger  and  testing  related  tools. 

The  documentation  for  the  Rational  debugger  includes  an  introductory  over¬ 
view  of  the  debugger  functions  and  naming  conventions,  a  section  giving 
detailed  information  about  each  debugging  procedure  and  the  types  of  spe¬ 
cial  Debug  procedure  parameters,  and  an  index  to  debugging  topics  that 
covers  technical  terms  and  procedure  and  type  names.  This  documentation 
should  be  adequate  for  any  user  to  teach  himself  how  to  use  the  debugger. 
The  Basic  Operations  Manuai  provides  four  pages  of  step-by-step  instruc¬ 
tions  of  common  debugger  operations  designed  to  help  the  novice  user  get 
started. 

Describe  any  noted  Inconsistencies  exhibited  by  the  Environment. 

There  are  no  noteworthy  inconsistencies  exhibited  by  the  environment. 

Describe  the  helpfulness  of  the  online  assistance,  especially  as  It  re¬ 
lates  to  unit  testing  and  debugging. 

The  online  assistance  provides  descriptions  of  all  debugging  procedures.  It 
does  not  include  the  introductory  material  or  description  of  procedure 
parameter  types  provided  in  the  written  documentation.  In  providing  infor¬ 
mation  about  a  debugging  procedure,  the  online  assistance  is  as  helpful  and 
easier  to  use  than  the  written  documentation  since  it  is  basically  an  online 
version  of  the  written  documentation  with  searches  on  name  fragments  of  the 
debugging  procedures  added.  In  addition,  the  online  help  immediately  pro¬ 
vides  a  description  of  any  procedure  bound  to  a  key  whenever  the  user 
presses  the  <Help  on  key>,  followed  by  the  key  of  interest. 

Do  the  analysis  tools  use  an  underlying  database  to  store  and/or 
retrieve  program  related  Information? 

No  supported  analysis  tools  are  available. 

How  accessible  are  the  underlying  OS  tools  from  within  the  debugger? 

There  is  no  underlying  operating  system  for  the  Rational  Environment.  For 
the  availability  of  Rational  Environment  tools  while  debugging,  see  TD43. 

How  accessible  Is  online  assistance  from  within  the  debugger? 

Very  accessible,  it  is  the  same  as  from  outside  the  debugger. 

How  Informative  are  the  debugger  error  messages? 

In  general,  they  are  very  informative. 

How  Informative  are  the  test  manager  error  messages? 

No  test  manager  tools  are  available. 
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TD52  How  tolerant  of  simple  errors  is  the  test  manager? 

No  test  manager  tools  are  available. 

TD53  How  tolerant  of  simple  errors  is  the  debugger? 

The  debugger  describes  the  problem  in  a  message  and  highlights  the  line  in 
which  the  error  occurred.  A  more  detailed  explanation  of  the  error  is  usually 
provided  if  the  <Explain>  key  is  pressed. 

TD54  Qualitatively  describe  the  response  times  for  Interacting  with  the 

debugger. 

Responses  are  instantaneous  for  most  operations.  There  does  seem  to  be  a 
startup  time  associated  with  the  debugger  of  several  seconds. 

TD55  Qualitatively  summarize  the  teaming  curve  as  It  applies  to  using  the 

environment  for  unit  testing  and  debugging. 

The  debugger  is  a  powerful  tool.  Some  learning  is  required  to  become  ac¬ 
quainted  with  all  its  capabilities.  The  basic  operations  of  stepping  through  a 
program,  setting  breakpoints,  and  displaying  object  values  are  very  easy  to 
learn  and  to  use. 


5.5.  Unit  Testing  and  Debugging  Anaiysis 

5.5.1.  Functionality 

There  are  no  tools  for  test  harness  generation,  regression  testing,  or  test  management. 

There  are  no  tools  for  performance  analysis.  However,  the  R1000  is  intended  as  a  universal  host 
development  system.  Since  code  generated  for  the  R1000  will  never  run  on  target  machines,  a 
performance  analyzer  is  more  important  for  the  target  environments  than  for  the  R1000.  Perfor¬ 
mance  patterns  on  the  R1000  should  be  expected  to  differ  from  performance  patterns  on  targets 
since  the  R1000  has  hardware  optimizations  for  implementing  certain  Ada  operations  that  will 
very  likely  not  exist  for  target  machines.  The  R1000  has  target  build  tools  that  can  be  used  to 
develop  code  that  will  be  recompiled  on  target  machines  that  support  an  APSE.  The  recom¬ 
pilation  is  driven  by  a  script  generated  by  the  R1000.  If  the  target  machine  APSE  includes  a 
performance  coverage  analyzer,  then  that  tool  will  be  available  to  examine  programs  developed 
on  the  R1000. 

The  browsing  capability  in  combination  with  the  debugger  provides  a  very  powerful  tool.  Stepping 
through  code  while  the  next  line  to  be  executed  is  highlighted  in  a  window  makes  source-level 
debugging  easy,  as  does  the  ability  to  display  variable  definitions  and  uses  interactively. 

The  Rational  Environment  debugger  also  has  a  full  complement  of  commands  for  setting,  reset¬ 
ting,  and  displaying  breakpoints  and  tracepoints.  Rational  breakpoints  can  be  defined  so  that 
they  will  break  only  when  the  code  containing  the  breakpoint  is  called  by  a  specific  task  or  after  a 
certain  number  of  executions.  Rational  tracepoints  do  not  display  values;  they  simply  print  a 
message  indicating  that  some  event  has  taken  place  in  a  task.  Commands  are  provided  to 
determine  whether  the  debugger  breaks  on  exceptions  or  propagates  them.  This  behavior  can 
be  localized  by  task  and  by  code  location.  For  example,  the  debugger  could  be  set  to  propagate 
all  exceptions  except  ones  raised  in  a  specific  procedure  when  called  by  a  specific  task.  Com- 
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mands  are  also  provided  to  stop  and  start  the  execution  of  tasks  and  to  display  task  states. 
There  are  commands  for  stepping  the  execution  of  programs  by  statements  or  by  events  (such  as 
making  or  returning  from  procedure  calls),  to  display  program  variable  values,  and  to  modify 
program  variable  values.  The  debugger  also  provides  a  facility  for  defining  how  the  debugger  will 
display  user-aeated  types  such  as  linked  lists.  This  functionality  was  not  tested  by  the  exper¬ 
iment. 

5.5.2.  Performance 

No  recompilation  is  required  to  allow  a  program  to  be  run  under  control  of  the  debugger.  There 
does  appear  to  be  a  startup  time  assodated  with  the  debugger,  but  it  is  minimal  compared  with 
the  time  that  would  be  required  by  a  recompilation.  The  debugging  and  browsing  facilities  are 
highly  Interactive. 

The  Delta  0  Release  of  the  Rational  Environment  did  have  a  problem  in  the  debugger.  The 
experiment  requires  the  setting  of  a  breakpoint  in  an  overloaded  function.  The  function  happens 
to  define  an  infix  operator.  The  debugger  was  unable  to  resolve  the  reference.  The  Rational 
Customer  Response  Center  indicated  that  they  were  aware  of  the  bug,  that  it  would  fixed  in  the 
next  release,  and  suggested  as  a  workaround  that  the  function  be  redefined  as  a  normal  function 
call.  The  workaround  was  easy  to  implement  using  the  browsing  and  incremental  editing  facil¬ 
ities.  It  also  corrected  the  problem  of  overload  resolution. 

5.5.3.  User  Interface 

Although  no  test  management  tools  are  provided  in  the  Rational  Environment,  they  could  be 
easily  constructed  given  the  nature  of  the  user  interface.  Procedures  can  be  written  in  Ada, 
making  use  of  the  programmatic  Ada  interface  to  such  packages  as  Program. Run_Job  and 
Rle_Utl I Itlos. Difference  to  manage  different  kinds  of  testing. 

The  debugger  always  operates  in  a  screen-oriented  mode  with  one  window  devoted  to  showing 
the  results  of  debugger  commands  and  another  window  devoted  to  showing  the  source  code 
being  debugged.  The  source  code  window  highlights  the  line  about  to  be  executed  when  step¬ 
ping  or  when  a  breakpoint  is  hit.  Most  common  debugger  commands  are  bound  to  function  keys 
and  will,  in  many  cases,  operate  on  objects  selected  in  the  source  code  window.  Thus,  displaying 
an  object’s  value  can  be  as  simple  as  selecting  the  object  in  the  source  code  window  and  press¬ 
ing  the  Debug  Put  key.  The  ability  to  browse  code  is  completely  integrated  with  the  debugger, 
and  the  browsing  interface  is  consistent  with  the  debugger  interface.  In  general,  the  debugger 
interface  is  unusually  easy  to  learn  and  use. 

The  Rational  debugger  interface  is  consistent  with  the  overall  Rational  Environment  interface. 
Thus,  a  user  familiar  with  the  rest  of  the  Rational  Environment  will  already  know  the  debugger 
and  browsing  interface  and  needs  only  to  learn  the  debugger  commands. 
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5.5.4.  System  Interface 

Because  the  Rational  Environment  is  the  operating  system  for  the  Rational  R1000  series  com¬ 
puters,  there  is  no  interface  to  tools  of  an  underlying  operating  system.  The  debugger  and 
browsing  facility  are  weil  integrated  into  the  Environment  and  actually  sold  as  part  of  the  Rational 
Environment.  The  debugger  and  the  browsing  facility  are  also  completely  integrated. 
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6.  Prototype  ACEC 
6.1.  Introduction 

The  final  experiment  of  the  Environment  Evaluation  Methodology  is  the  compilation  and  execution 
of  the  Ada  Compiler  Evaluation  Capability  (ACEC)  test  suite  that  was  assembled  by  the  Institute 
for  Defense  Analysis  (IDA).  The  version  of  the  ACEC  that  was  publicly  available  and  used  for  this 
evaluation  is  described  in  the  User's  Manual  for  the  Prototype  Ada  Compiler  Evaluation 
Capability,  Version  1,  by  Audrey  A.  Hook,  Gregory  A.  Riccardi,  Michael  Vilot  and  Stephen  Welke, 
Institute  for  Defense  Analysis,  October  1985. 

The  SEI  experience  with  the  ACEC  is  described  in  Chapter  Eight  of  Evaluation  of  Ada 
Environments.  Since  the  prototype  ACEC  did  not  provide  any  capability  for  analyzing  the  ACEC 
results,  the  SEI  developed  an  analysis  program  that  generates  statistics  from  the  ACEC  results 
files.  The  SEI  discovered  that  the  present  design  of  the  ACEC  does  not  generate  measurements 
of  sufficient  reliability  for  the  ACEC  suite  to  be  used  for  its  primary  purpose,  the  evaluation  of 
individual  language  features.  Lack  of  reliability  was  indicated  by  two  problems:  lack  of 
repeatability  and  negative  deltas.  Repeatability  was  directly  tested  using  DEC’S  VAX  Ada  com¬ 
piler  by  running  a  subset  of  the  ACEC  three  times.  Variations  in  CPU  usage  of  up  to  4%  were 
found  for  compilation  and  of  up  to  50%  for  run  time.  The  repeatability  problems  led  the  SEI  to  the 
following  conclusion: 

This  jitter,  if  representative  of  other  environments,  does  not  invalidate  the  observed 
ratios  of  overall  compiler  performance,  but  it  does  invalidate  any  fine-grained  measure¬ 
ments,  particularly  any  differential  statistics. 

Negative  deltas  occurred  when  a  test  using  a  language  feature  took  less  time  than  a  control  test 
that  did  not  use  the  language  feature.  Clearly,  negative  deltas  are  a  byproduct  of  the  non¬ 
repeatability  of  a  measurement  that  was  measured  directly  with  VAX  Ada.  Negative  deltas  ap¬ 
peared  in  the  results  of  VAX  Ada  running  under  VMS,  Verdix’s  VADS  compiler  running  under 
ULTRIX  (DEC  Unix),  and  with  the  Rational  R1000.  The  SEI  conclusion  about  using  the  ACEC  to 
measure  individual  language  feature  performance  is  that "...  the  differential  statistics  produced  by 
the  analysis  program  must  be  viewed  with  extreme  skepticism"  and  that "  ...  no  conclusions  can 
be  drawn." 

In  accordance  with  the  SEI  finding,  the  report  on  the  results  of  implementing  the  ACEC  on  the 
Rational  R1000  does  not  discuss  individual  language  features.  The  aggregate  measures  for  all 
tests  and  the  aggregate  measures  for  each  of  the  major  test  categories  (normative  performance, 
normative  capacity,  optional  performance,  and  optional  special  algorithms)  are  reported  for  the 
compilation  of  the  ACEC  from  source  state  to  coded  state.  According  to  the  IDA  User's  Manual 
for  the  Prototype  ACEC,  Version  1,  the  optional  special  algorithms  tests  "are  combinations  of 
language  constructs  that  are  characteristic  of  synthetic  benchmark  programs."  As  such,  the  ag¬ 
gregate  measures  for  just  this  category  are  reported  for  compilation  from  ASCII  text  file  format  to 
a  loaded  main  program. 
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6.2.  Implementing  the  Prototype  ACEC 

The  ACEC  was  implemented  on  the  Rational  R1000  using  the  Delta  0  Release  of  the  Rational 
system  software.  Since  the  command  language  of  the  Rational  R1000  is  Ada,  and  since  Ada 
procedure  calls  were  available  to  obtain  the  required  statistics  (such  as  CPU  time)  used  by  a  job, 
generation  of  the  support  software  required  to  drive  the  ACEC  suite  was  easy.  (See  Appendix  C 
for  listings  of  the  support  software.)  No  problems  were  encountered  using  the  Rational  Environ¬ 
ment  to  compile  the  components  of  the  support  software  supplied  with  the  ACEC.  The  Environ¬ 
ment  was  dedicated  to  running  the  ACEC  suite  for  each  run. 

6.2.1.  Implementation  Choices 

The  ACEC  test  suite  collects  compilation  and  execution  timings  based  on  a  traditional  compile, 
link,  load,  and  execute  cycle.  The  Rational  Environment  departs  from  the  traditional  cycle,  and  it 
is  difficult  to  arrive  at  a  timing  method  that  provides  a  fair  comparison  to  other  APSEs. 

There  are  three  areas  where  implementation  choices  were  made  so  that  the  collected  data  would 
be  more  comparable  to  previously  studied  APSEs.  First,  the  ACEC  tests  could  be  compiled  from 
a  text  file  to  a  coded  state  or  from  an  Ada  object  in  source  state  to  a  coded  state.  Second,  linking 
could  occur  when  the  tests  were  run  or  when  they  were  compiled.  Finally,  compilation  time  could 
reflect  the  cost  of  loading  a  main  program  or  execution  time  could  reflect  the  cost  of  loading. 

Two  sets  of  results  are  presented.  The  first.  Section  6.3.1  shows  timings  collected  from  the  com¬ 
pilation  and  execution  of  all  four  categories  of  the  ACEC  test  suite.  Compilation  time  in  this  table 
was  measured  as  the  time  to  promote  an  Ada  object  in  source  state  to  coded  state  and  to  link  the 
object.  Compiling  from  Ada  objects  in  source  state  eliminates  the  parsing  which  traditional  com¬ 
pilers  perform  when  starting  with  text  files.  Because  compilation  on  the  Rational  is  typically 
performed  on  Ada  objects  in  source  state,  these  results  are  significant  when  compared  with  the 
other  APSE  results. 

The  second  set  of  results  (see  Section  6.3.3)  shows  timings  collected  from  the  compilation  and 
execution  of  only  the  architecture  category  "optional  spedal  algorithms."  Compilation  time  was 
collected  as  the  time  to  compile  from  text  to  coded  state  plus  the  time  to  produce  a  loaded  main 
program.  The  optional  special  algorithms  were  chosen  because  they  represent  more  standard 
benchmark-type  code,  rather  than  code  that  is  written  to  test  language  features.  Note  that  this 
compilation  time  also  incurs  the  cost  of  "pretty  printing"  the  source  code.  More  traditional  envi¬ 
ronments  provide  formatting  as  a  function  separate  from  compilation. 

For  both  sets  of  results,  the  pragma  Main  was  added  to  the  source  in  order  to  force  compile  time 
linkage.  This  is  not  standard  or  recommended  practice  when  developing  or  maintaining  Ada  units 
in  the  Rational  Environment,  but  was  done  here  to  make  results  comparable  to  the  results  from 
other  APSEs.  Link  and  load  usually  occur  when  execution  of  a  program  is  requested. 

One  incompatibility  between  the  architecture  of  the  ACEC  suite  and  the  Rational  treatment  of 
program  libraries  had  to  be  resolved  to  enable  the  use  of  Ada  objects.  Ten  of  the  text  files  in  the 
suite  contained  non-nested  compilation  units  of  the  following  form; 


146 


CMU/SEI-88-TR-21 


package  S2nall__Unit  is 


end  Small_nnit; 
with  Small_Unit ; 

procedure  An_ACEC_Main_Procedure  is 


end  An_ACEC_Main_Procedure; 

These  were  the  tests  BSRCA2,  BSRCA3,  CENTB2,  NULLA1,  NULLA2,  PKGEA1,  PKGEA2, 
PKGSA1,  PKGSA2  and  SHARA2.  The  Rational  library  system  stores  non-nested  compilation 
units  in  separate  Ada  objects.  Thus,  the  packages  contained  in  the  ACEC  text  files  are  split  into 
multiple  Ada  objects.  The  objects  split  out  of  the  text  files  must  be  compiled  into  the  program 
libreiry  before  the  test  harness  can  compile  the  ACEC  main  procedures.  To  include  the  compi¬ 
lation  times  of  the  packages  split  out  of  the  ACEC  text  files,  a  separate  record  was  kept  of  their 
compilation  times.  The  times  in  the  compilation  log  generated  by  the  main  ACEC  test  harness 
were  then  adjusted  by  hand  for  the  ten  test  programs  that  contained  non-nested  compilation 
units. 

6.2.2.  Problems  Found  in  the  ACEC  Suite 

When  the  ACEC  suite  was  first  executed,  the  Rational  compiler  detected  four  erroneous  ACEC 
programs  (LOSCA1,  LOSCA2,  SRTEA1  and  SRTEA2)  at  runtime.  These  erroneous  programs 
have  not  been  detected  by  any  other  Ada  runtime  system.  Erroneous  programs  use  the  lan¬ 
guage  incorrectly  but  need  not  be  caught  by  either  an  Ada  compiler  or  by  Ada  runtime.  Those 
incorrect  uses  that  are  treated  as  erroneous  are  specified  in  the  Ada  Language  Reference 
Manual,  (ANSI/MIL-STD-1815A-1983).  In  each  case  where  the  Rational  Environment  detected 
an  erroneous  program,  an  uninitiated  variable  was  passed  to  a  procedure.  Passing  a  variable  as 
an  in  or  in  out  parameter  causes  the  variable  to  be  evaluated,  and  evaluation  of  an  uninitialized 
variable  is  defined  as  erroneous.  Once  the  erroneous  programs  were  detected,  they  were  cor¬ 
rected  by  initializing  variables  in  their  declaration.  Rational  indicates  this  class  of  erroneous 
program  by  raising  numeric  errors,  regardless  of  the  type  of  the  uninitialized  variable. 

Another  problem  was  found  with  the  programs  BSRCA2  and  BSRCA3.  Both  assume  that  an 
implementation  has  no  predefined  integer  types  with  a  range  greater  than  the  predefined  type 
Integer.  This  is  not  the  case  with  the  Rational,  where  the  largest  integer  type  is  Long_lnteger. 
The  problem  arose  when  assigning  System. Min_lnt  to  a  variable  of  type  Integer.  The  Ada  Lan¬ 
guage  Reference  Manual  (see  [2])  defines  System. Minjnt  to  be  the  smallest  value  of  all 
predefined  integer  types  in  an  implementation.  Assigning  System. Minjnt,  which  on  the  Rational 
had  the  value  Long_lnteger’ First,  to  a  variable  of  type  Integer  caused  a  constraint  error.  The 
problem  was  corrected  by  changing  the  type  of  the  offending  variable. 

Two  capacity  tests,  BLEMA2  and  RCDSA2,  generated  no  instrumentation  measurements. 
BLEMA2  contains  sixty-five  nested  blocks.  Compilation  determined  that  the  program  was  seman- 
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tically  and  syntactically  correct,  but  object  code  was  not  generated  since  this  exceeded  the  com¬ 
piler  capacity  of  fifteen  static  nestings.  The  problem  was  reported  by  the  compiler  with  the  follow¬ 
ing  message: 

BLEMil2  could  not  be  proiaoted  to  coded; 
it  was  promoted  to  installed.  Static 
nesting  level  exceeds  15  (note: 
inserting  a  package  into  your  sequence 
of  nested  blocks /subprograms  will 
fix  this) . 

RCDSA2  was  a  capacity  test  that  used  a  record  with  400  fields.  This  exceeded  the  documented 
Rational  limit  of  256  fields,  and  generated  the  following  runtime  error  message: 
Xnstruction_Error (type  mismatch) . 

In  both  these  cases,  the  ACEC  performed  its  job,  which  was  to  detect  capacity  limits  in  the 
compiler  being  tested. 

A  problem  previously  detected  in  the  Design  and  Development  Experiment  also  affects  the  ACEC 
results;  a  procedure  that  compiles  a  program  cannot  also  measure  the  size  of  the  resulting  Ada 
object.  An  attempt  to  do  so  generates  a  random  number.  Thus,  the  object  code  size  field  is  not 
available  in  the  test  results.  Since  object  code  generated  by  the  Rational  is  stored  in  Ada  objects 
that  contain  far  more  information  than  an  object  code  file,  the  size  of  Ada  objects  is  not  an 
indication  of  the  size  of  Rational’s  object  code.  There  is  no  way  to  measure  object  code  size 
directly.  Section  6.3.4  is  provided  as  a  means  to  compare  disk  utilization  for  executable  images 
with  other  APSEs. 

Once  the  changes  to  individual  tests  described  in  Section  6.2.1  were  made,  the  Rational  Environ¬ 
ment  had  no  trouble  compiling  and  executing  the  prototype  ACEC  suite. 
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6.3.  Numeric  Results 


6^.1.  Aggr«gat«  Maasuramants  for  All  Tasts 


MEAN  VALUE 

Rational 

VMSA/AXSat 

Unocal  ADS 

Compltatlon  Quantity 

Eiapaad  TVna 

30.0(1.0) 

52.6(1.6) 

61.6(2.1) 

CPU  Tima 

24.0(1.0) 

15.2  (0.6) 

44.6(1.6) 

Inatrumantadon  Quantity 

Elapaad  Tima 

4.4  (1.0) 

16.2(3.7) 

23.6  (5.4) 

CPU  Tima 

4.2  (1.0) 

16.2(3.0) 

0.2  (0.0) 

Run  Tima  Quantity 

Elapaad  Tima 

15.8(1.0) 

26.8(1.6) 

36.7(2.3) 

CPU  Tima 

5.1  (1.0) 

17.0(3.3) 

23.3  (4.6) 

MINIMUM  VALUE 

Rational 

VMSA^AXSat 

Unix/VADS 

Compiation  Quantity 

Elapaad  Tima 

6.7  (1.0) 

30.6(5.0) 

30.2  (5.0) 

CPU  Tima 

4.8  (1.0) 

6.3  (1.3) 

26.3  (5.5) 

Inatrumantalion  Quant'ty 

Elapaad  Tima 

0.0  (. ) 

0.0  (. ) 

0.2  (■  ) 

CPU  r»ma 

o.o(.) 

0.0  (. ) 

O.O(-) 

Run  Tima  Quantity 

Eiapaad  Tima 

11.2(1.0) 

12.2(1.1) 

12.6(1.1) 

CPU  Tima 

1. 0(1.0) 

0.6 (0.6) 

0.5  (0.5) 

MAXIMUM  VALUE 

Rational 

VMSA/AXSat 

Unocal  ADS 

Compilation  Quantity 

Elapaad  Tima 

1780.1  (1.0) 

207.2  (0.2) 

606.1  (0.3) 

CPU  Tima 

1684.6(1.0) 

121.3(0.1) 

500.2  (0.4) 

Inatrumantalion  Quantity 

Eiapaad  Tima 

204.7(1.0) 

402.4(2.0) 

460.5  (2.2) 

CPU  Tima 

201.6(1.0) 

402.0  (2.0) 

4.6  (0.0) 

Run  Tima  Quantity 

Eiapaad  Tma 

216.1  (1.0) 

415.2(1.0) 

473.6  (2.0) 

CPU  Tima 

202.6(1.0) 

402.6(2.0) 

450.0  (2.3) 

Tabu  t-1 :  Aggragatad  Maaauramanti  for  All  Tatta 
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63.2.  Aggr»gat«d  Maasuramants  for  Each  Architactura  Catagory 


COMPILATION-TIME:  ELAPSED  TIME  (SECONDS)  TOTALS 


ARCH.  CATEGORY 

# TESTS 

rtnl’ 

DEC* 

VADS* 

MEAN.VALUE 

ALL^CATEOORIES 

173 

30.0  (1.0) 

52.8  ( 1.8) 

81.8(2.1) 

NORMATIVE.PERFORMANCE 

131 

15.6(1.0) 

40.8  ( 3.2) 

58.1  (3.7) 

NORMATlVE_CAPACITY 

11 

213.0  (  1.0) 

80.2  ( 0.3) 

120.8(0.6) 

OPTIONAL_FEATURES 

3 

67.0  ( 1.0) 

130.0  (  2.0) 

01.0  ( 1.3) 

OPDONAL.ALQORITHMS 

28 

21.0  ( 1.0) 

50.3  ( 2.4) 

53.0  ( 2.5) 

MINIMUM.VALUE 

ALL^CATEGORIES 

173 

6.7  ( 1.0) 

30.8  ( 5.0) 

30.2  ( 5.0) 

NORMATIVE^PERF. 

131 

8.7  ( 1.0) 

30.8  ( 5.0) 

30.3  ( 5.8) 

NORMATlVE.CAPACrrY 

11 

7.7  (1.0) 

40.4  (  5.2) 

42.2  ( 5.5) 

OPTIONAL.FEATURES 

3 

15.2  ( 1.0) 

45.6  ( 3.0) 

47.3(3.1) 

OPnONAL_ALQS. 

28 

0.2  ( 1.0) 

30.0  ( 4.3) 

30.2  ( 4.3) 

MAXMUM_VALUE 

ALU.CATEGORIES 

173 

176ai  (  1.0) 

207.2  (  0.2) 

806.1  ( 0.3) 

NORMATlVE_PERF. 

131 

05.1  ( 1.0) 

88.5  (  0.0) 

1 35.8  (  1.4) 

NORMATIVE^CAPACrTY 

11 

1760.1  (  1.0) 

158.2  (  0.1) 

808.1  (  0.3) 

OPDONAL.FEATURES 

3 

132.1  ( 1.0) 

207.2  (  2.2) 

151.0(  1.1) 

OPDONAL^ALQORITVIMS 

28 

65.0  ( 1.0) 

00.7  ( 1.5) 

81.1  (1.2) 

COMPILATION-TIME:  TOTAL  CPU  TIME 

(SECONDS) 

— -  TOTALS 

ARCH.  CATEGORY 

#  TESTS 

RTNL 

DEC 

VADS 

MEAN.VALUE 

ALL.CATEQORIES 

173 

15.1  ( 1.0) 

15.2  ( 1.0) 

44.8(3.0) 

NORMATlVE_PERFORMANCE 

131 

11.7  ( 1.0) 

13.0(1.1) 

40.8  ( 3.5) 

NORMATlVE.CAPACrrY 

11 

201.0  ( 1.0) 

33,7  ( 0.2) 

106.2(0.5) 

OPTIONAL^FEATURES 

3 

30U)(  1.0) 

46.8  (  1.2) 

63.2  ( 1.8) 

OPTIONAL.ALQORITHMS 

28 

15.8  ( 1.0) 

14.6(0.0) 

38.4  ( 2.4) 

MtNIMUM.VAUIE 

ALL.CATEQORIES 

173 

4.8  (1.0) 

8.3  ( 1.3) 

28.3  (  5.5) 

NORMATIVE.PERFORMANCE 

131 

4.8  (1.0) 

7.3  (1.5) 

27.4(5.7) 

NORMATIV  E_C  APACITY 

11 

4.0  ( 1.0) 

8.3  (1.7) 

30.3  ( 8.2) 

OPTIONAL.FEATURES 

3 

0.3  ( 1.0) 

8.4  ( 0.0) 

26.0  ( 3.0) 

OPDONAL.ALQORITH  MS 

26 

6.2  ( 1.0) 

8.3  ( 1.0) 

28.3  ( 4.2) 

MAXOyiUM.VALUE 

ALL.CATEQORIES 

173 

1884.6  (  1.0) 

121 .3(  0.1) 

500.2  ( 0.4) 

NOR  MATIVE^PE  RFORMANCE 

131 

88.4  ( 1.0) 

55.8  (  0.8) 

00.0(1.2) 

NORMATIVE.CAPACITY 

11 

1884.8  ( 1.0) 

121.3  (  0.1) 

500.2  (  0.4) 

OPnONAL_FEATURES 

3 

77.1  (1.0) 

106.4(  1.4) 

107.4(  1.4) 

OPTIONAL^LQORITH  MS 

28 

45.2  ( 1.0) 

30.3  ( 0.0) 

61.8  (  1.4) 

Tabla$-2: 

Compilation  Raautta 

'Rational  1000  Modal  200*20,  Rational  Environmant  Ralaaaa,  DaKaO. 

'Digital  Equipmant  Corporation  Ada  Compilation  Syatam  Varaion  1 .2,  VMS,  6  magabytaa  main  mamory,  102  magdbytaa  disk  apaca. 
Vardix  Ada  Davalopmant  Sya^m,  Varaion  5.1 ,  ULTRIX  Varaion  1 .2,  6  magabytaa  main  mamory,  202  magabytaa  dlak  ^aca. 
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INSTRUMENTATION:  ELAPSED  TIME  (SECONDS)  —  TOTALS 


ARCH.  CATEGORY 

#  TESTS 

RTNL 

DEC 

VADS 

|y£AN_VALUE 

ALL^CATEGORIES 

171 

4.4  (1.0) 

16.2(3.7) 

23.6  ( 5.4) 

NORMATlVE_PERFORMANCE 

131 

3.4  (  1.0) 

1 7.9  (  5.3) 

26.1  ( 7.7) 

NORMATtVE_CAPACITY 

9 

1.3  ( 1.0) 

1.3(  1.0) 

2.4  (1.8) 

OPTION  AL^FEATURES 

3 

1.1  (1.0) 

8.4  (  7.6) 

4.9  (4.5) 

OPTION  AL^ALQORITH  MS 

28 

10.3(  1.0) 

15.0  (  1.5) 

21.7(2.1) 

MINIMUM^VALUE 

ALL_CATEGORIES 

171 

0.0  (. ) 

0.0  (. ) 

0.2(  .) 

NORMATIVE_PERFORMANCE 

131 

0.1  (1.0) 

0.0  (  0.0) 

0.3  ( 3.0) 

NORMATIVE^CAPACITY 

9 

0.0  (  -  ) 

0.0  (  - ) 

0.2  (. ) 

OPTION  AL.FEATU  RES 

3 

0.7  ( 1.0) 

3.5  ( 5.0) 

4.0  (  5.7) 

OPTION  AL.ALGORITHMS 

28 

0.0  (. ) 

0.0  (. ) 

0.2(  .) 

MAXMUM^VALUE 

ALL.CATEQORIES 

171 

204.7  (  1.0) 

402.4  (  ^0) 

460.5  (  ^2) 

NORMATIVE^PERFORM  ANC  E 

131 

96.2  ( 1.0) 

402.4  (  4.2) 

460.5  (  4.8) 

NOR  MAT1VE_CAP  ACHY 

9 

7.2  ( 1.0) 

4.9  ( 0.7) 

11.8  (  1.8) 

OPTION  AL_FEATU  RES 

3 

1.4  (1.0) 

11.3(  8.1) 

5.4  ( 3.9) 

OPTION  AL^ALGO  RITH  MS 

28 

204.7  (  1.0) 

289.9  (  1.4) 

358.0  (  1.7) 

INSTRUMENTATION: 

CPU  TIME  (SECONDS)  — 

TOTALS 

ARCH.  CATEGORY 

#  TESTS 

RTNL 

DEC 

VADS 

MEANJ/ALUE 

ALL_CATEQORlES 

171 

4.2  (  1.0) 

16.2  (3.9) 

0.2  (0.0) 

NORMATIVE^PE  RFORM  ANCE 

131 

3.3  ( 1.0) 

17.8(5.4) 

0.2  (0.1) 

NOR  MAT1VE_CAP  ACHY 

9 

1.0  ( 1.0) 

1.3  ( 1.3) 

0.0  ( 0.0) 

0PT10NAL_FEATURES 

3 

1.1  (1.0) 

8.4  (7.7) 

0.4  ( 0.3) 

0PT10NAL_ALQ0RITHMS 

28 

9.7  ( 1.0) 

14.7  (  1.5) 

0.4  ( 0.0) 

MINIMUM^VALUE 

ALL^CATEGORIES 

171 

0.0(  -) 

0.0(  •) 

0.0  (. ) 

NORMATfVE_PERFORMANCE 

131 

0.1  (  1.0) 

0.0  (  0.0) 

0.0  (  0.0) 

NORMATIVE_CAPACITY 

9 

0.0  (. ) 

0.0  (  - ) 

0.0  (. ) 

OPTION  AL^FEATU  RES 

3 

0.7  (  1.0) 

3.5  (5.1) 

0.0  ( 0.0) 

OPTION  AL_ALGORITH  MS 

28 

0.0  (. ) 

0.0  (. ) 

0.0(  .) 

MAXMUM  VALUE 


ALL^CATEGORIES 

171 

201.6  (  1.0) 

402.0  (  2.0) 

4.6  ( 0.0) 

NOR  MAT1VE_PE  RFORM  ANC  E 

131 

94.7  ( 1.0) 

40^0  (  4.2) 

4.8  ( 0.0) 

NORMATlVE_CAPACnY 

9 

4.5  (1.0 

4.9)  (1.0) 

0.0  (  0.0) 

OPTIONAL_FEATURES 

3 

1.3  (1.0) 

11.3(8.7) 

1.0  (  0.8) 

OPTION  AL_ALGORITH  MS 

28 

201.6  (  1.0) 

289.5  (  1.4) 

4.5  ( 0.0) 

TabU  S-3:  Initrumantation  Rasul ta 
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RUN-TIME:  ELAPSED  TIME 

(SECONDS)  —  TOTALS 

ARCH.  CATEGORY 

# TESTS 

RTNL 

DEC 

VADS 

MEAN_VALUE 

ALL.CATEQORIES 

171 

15.8(1.0) 

28.8  ( 1.8) 

36.7  ( 2.3) 

NORMATIVE.PERFORMANCE 

131 

14.8(1.0) 

30.4  ( 2.0) 

39.1  ( 2.8) 

NORMATIVE.CAPACfTY 

9 

1 7.7  ( 1.0) 

13.7(0.8) 

15.5(0.9) 

OPTIONAL^FEATURES 

3 

12.8  ( 1.0) 

20.8(1.6) 

18.2(1.4) 

OPTION  AL^ALGORTTH  MS 

28 

21.7  ( 1.0) 

27.6(1.3) 

34.8(1.8) 

MINIMUM^VALUE 

ALL.CATEGORIES 

171 

11.2(1.0) 

12.2(1.1) 

12.8(1.1) 

NORMATIVE.PERFORMANCE 

131 

1 1.3  ( 1.0) 

12.4(  1.1) 

12.8(1.1) 

NORMAHVE.CAPACmr 

9 

11.3  ( 1.0) 

12.2(1.1) 

13.2(1.2) 

0PT10NAL.FEATURES 

3 

11.9(1.0) 

15.7  ( 1.3) 

17.3  ( 1.5) 

OPTtONAL.ALQORlTHMS 

28 

11.2(1.0) 

12.3  ( 1.1) 

13.2(1.2) 

MAXMUM^VAUJE 

Aa^CATEQORIES 

171 

218.1  ( 1.0) 

41 5.2  (  1.9) 

473.8  (  2.2) 

NORMATlVE_PERFORMANCE 

131 

107.4  ( 1.0) 

415.2(3.9) 

473.8  ( 4.4) 

NORMATIVE.CAPACnY 

9 

19.3  ( 1.0) 

17.3(0.9) 

25.0  ( 1.3) 

OPTIONAL.FEATURES 

3 

13.7(1.0) 

23.9  (  1.7) 

18.8  ( 1.4) 

OPnONAL_ALQORrrHMS 

28 

218.1  (  1.0) 

302.3  ( 1.4) 

370.8  (  1.7) 

RUN-TIME:  CPU  TIME  (SECONDS) 

ARCH.  CATEGORY 

—  TOTALS 

# TESTS 

RTNL 

DEC 

VADS 

MCAN_VAUjE 

ALL.CATEQORIES 

171 

5.1  (1.0) 

17.0(3.3) 

23.3  ( 4.8) 

NORMATIVE.PERFORMANCE 

131 

4.2  (  1.0) 

18.8(4.4) 

25.8(8.1) 

NORMATIVE.CAPACrrY 

9 

2.0  ( 1.0) 

1.9  ( 1.0) 

2.8  (1.4) 

OPnONAL.FEATURES 

3 

2.1  ( 1.0) 

9.5  (4.5) 

4.8  ( 2.2) 

OPnONAL^ALOORTTHMS 

28 

10.7(1.0) 

15.4(1.4) 

21.5(2.0) 

MINIMUM^VALUE 

ALL^CATEQORIES 

171 

1.0(1.0)0.6(0.8) 

0.5  ( 0.5) 

NOR  MAT1VE_PERFORMANCE 

131 

1.0  (1.0) 

0.7  (  0.7) 

0.8  ( 0.8) 

NORMATlVE_CAPACnY 

9 

1.0  ( 1.0) 

0.8  ( 0.6) 

0.5  ( 0.5) 

OPT10NAL_FEATURES 

3 

1.7  (1.0) 

4.1  (2.4) 

2.2  ( 1.3) 

OPTIONAL.ALQORITHMS 

28 

1.0  (  1.0) 

0.8  ( 0.8) 

0.8  (0.6) 

MAXMUM^VALUE 

ALL_CATEQOR)ES 

171 

202.8  ( 

1.0) 

402.8  (  2.0) 

459.9  ( 2.3) 

NORMATlVE_PERFORMANCE 

131 

95.7  ( 

1.0) 

402.8  ( 4.2) 

459.9  ( 4.8) 

NORMATIVE_CAPACITY 

9 

5.5  ( 

1.0) 

5.5  (1.0) 

12.1  (2.2) 

OPnONAL_FEATURES 

3 

2.4  ( 

1.0) 

12.8(5.3) 

5.8  (2.4) 

OPTIONAL^LQORITHMS 

28 

202.8  ( 

1.0) 

290.2  (  1.4) 

357.8  (  1.8) 

T«bto  G>4:  Run-Tinrw  RMuitt 
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6J.3.  MMSurcmcnt  on  28  Optional  Aigorithms  from  ACEC  Suita 


Rat. 

Rat. 

VMSA^AXSat"* 

Unix/VADS*" 

ALS*** 

S->C* 

T->L" 

MEAN  VALUE 

Elap««d  Tim*  (sac) 

21-0 

8^8 

50.3 

53.0 

777.8 

CPU  Tim*  (Mc) 

15.8 

26.1 

14.8 

38.4 

402.6 

MINIMUM  VALUE 

Bap««d  Tim* 

0.2 

28.5 

30.0 

30.2 

877.3 

CPU  Tim* 

8.2 

1^1 

8.3 

28.3 

428.0 

MAXIMUM  VALUE 

Eiap»*d  Tim* 

85.0 

145.0 

00.7 

81.1 

1285.8 

CPU  TIME 

45.2 

82,1 

30.3 

61.8 

771.7 

TabI*  8«S:  Compilat'on  Tima 

Rat. 

Rat. 

VMSA^AXSat 

Unix/VADS 

ALS 

S->C 

T->L 

MEAN  VALUE 

EJaptad  Tm*  (»*c) 

10.3 

10.3 

15.0 

21.7 

21.4 

CPU  Tim*  (mc) 

0.7 

0.7 

14.7 

0.4 

20.8 

MINIMUM  VALUE 

B«p**d  Tm* 

0.0 

0.0 

0.0 

0.2 

0.0 

CPU  Tim* 

0.0 

0.0 

0.0 

0.0 

0.0 

MAXIMUM  VALUE 

Elapaad  Tm* 

204.7 

206.8 

280.0 

358.0 

388.6 

CPU  TIME 

201.8 

201.5 

260.5 

4.5 

386.0 

Tabl*$-<: 

Inatrumontation  Quantity 

*  RationaJ  Sourc*  (pvMd)  to  Cod*d  Stmt*. 

**  ASCII  Taxt  to  Linkad  and  Load*d  via  ut*  of  pragma  Main, 

***  Compilation  tim*  indudas  compil*  and  fink  tim*. 
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Rat. 

S->C 

Rat. 

T->L 

VMSA^AXSet 

Unix/VADS 

ALS 

MEAN  VALUE 

Elapaad  Tima  (aac) 

21,7 

22,4 

27.6 

34.8 

45.6 

CPU  Tima  (aac) 

10.7 

10.6 

15.4 

21.5 

26.6 

MINIMUM  VALUE 

0apaad  Tima 

11.2 

11.5 

12,3 

13.2 

23.9 

CPU  Tima 

1.0 

1.0 

0.6 

0.6 

5.3 

MAXMUM  VALUE 

Ela(»ad  Tima 

216.1 

216.3 

302,3 

370.6 

410.3 

CPU  TIME 

202,6 

202.S 

290.2 

357.6 

391.6 

TabI*  S>7:  Run  Tim*  QuantiV 


ak«ra2  Ackannann  function  (taat) 

akara3  Ackarmann  function  (pragma  tuppraaa) 

barca2  BINARY  SEARCH  PKQ  AT  EXTREME  UMITS  OF  ITS  INDEX  TYPE:  LOWER 

barcaa  BINARY  SEARCH  PKQ  AT  EXTREME  UMITS  OF  ITS  INDEX  TYPE;  UPPER 

chaaa2  Char.  Strir>g  Saarch  (taat) 

ehaaaS  Char.  String  Saarch  (pra^a  auppraaa) 

facta2  RECURSIVE  FACTORIAL  FUNCTION 

hadra2  HEAPSORT  BENCHMARK  DRIVE  USES  XOBMHSPK 

inlqa2  A  FULL  INTEGER  QUEUE  USING  XOQUE  PACKAGE 

iaaqa2  GENERIC  SEQUENCE  MANIPULATION  PACKAGE.  SO  INTEGERS 

minia2  MINIMAL  PROGRAM  WITH  2  STMT  ,  1  DECLARATION 

m1oqa2  EMPTY  CHARACTER  QUEUE  USING  XOQUE  PACKAGE 

mtaaa2  EMPTY  SET  OF  ENUMERATION  TYPE  USING  XOSET  PACKAGE 

mtiaa2  EMPTY  SET  OF  INTEGERS  USING  XOSET  PACKAGE 

pgqua2  PUT.END  AND  GOT.END  WITH  AN  ENUMERATED  TYPE  USING  XOQUE  PKQ 

piala2  PI  Algorithm  (taat) 

prcoa2  PRODUCER/CONSUMER  PROBLEM 

puzza2  PUZZLE 

puzza3  PUZZLE  (PRAGMA  SUPPRESS) 

randa2  RANDOM  NUMBER  GENERATOR 

■haraZ  READERSAVRITERS  PROBLEM 

•iava2  Slava  of  Eratoathanaa  (taat) 

torta2  INSERTION  SORT  USING  XOSORT  PACKAGE 

aq10a2  PUT  10  INTEGERS  IN  SEQUENCE  AND  IF  EMPTY  USING  XOSEQ  PACKAGE 

•qpga2  PUT  AND  GET  10  INTEGERS  IN  SEQUENCE  USING  XOSEO  PACKAGE 

vpgaa2  VARIOUS  PUTS  AND  GETS  IN  SEQUENCE  USING  XOSEQ  PACKAGE 

whata2  WHETSTONE  INSTRUCTIONS  WITH  FLOATS 

whata3  WHETSTONE  INSTRUCTIONS  WITH  FLOATS  (PRAGMA  SUPPRESS) 


Tabla  $>•:  Optional  Algorithms  Programa 
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6^.4.  Comparison  of  Exacutabia  imaga  Siza 


Bytos 

Words 

Linss 

UAda 

1134 

81 

40 

MadAda 

9260 

1101 

289 

BigAda 

47411 

4995 

1436 

TablaSO:  Siza  of  Ada  Sourca  Compariaon  Programs 

Vsrdlx  Ads^ 

Aisys  3.2^ 

RstfonsI* * 

(kbytss) 

(kbytss) 

(kbytss) 

UAda  axacutabla 

64 

120 

53 

UAda  program  library 

76 

125 

N/A 

MadAda  axacutabla 

12 

120 

94 

MadAda  program  library 

129 

195 

N/A 

BigAda  axacutabla 

81 

136 

249 

BigAda  program  Ibrary 

245 

191 

N/A 

TabU  $-1 0:  Compariton  of  Exacutabia  and  Program  Library  Stzaa 


Vardix  Ada,  VADS  5.  MicroVAX  IIAJLTRIX  1.2 

'Alaya  3.2,  Sun  3/140,  OS  3.2 

*RatiorMj,  Modal  200*20,  Rationaj  Ertvtronmant  OaltaO 
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6.4.  Prototype  ACEC  Analysis 

When  compiling  from  Rational  source  code  state,  the  Rational  compiler  was  1 .8  times  faster  than 
VMSA/AXSet  and  2.1  times  faster  than  UnixA/ADS  in  terms  of  elapsed  time  on  an  average 
across  173  ACEC  Suite  Ada  programs.  Compiling  from  Rational  source  code  state  does  provide 
an  advantage  to  the  Rational  compiler,  as  parsing  has  already  occurred.  However,  it  is  not  an 
unreasonable  comparison  as  source  state  is  easily  achieved  using  the  Ada  Object  Editor.  Also, 
incremental  compilation  techniques  prevent  the  need  to  re-parse  an  Ada  program  once  it  has 
been  parsed  successfully. 

An  anomalous  figure  for  compile  time  is  presented  for  the  maximum  value  for  the  Normative 
Capacity  Tests.  The  elapsed  time  to  compile  is  1760.1  seconds.  The  particular  ACEC  test  which 
required  such  a  great  amount  of  time  for  compilation  was  Centb2,  described  in  the  User's  Manual 
for  the  Prototype  ACEC  as: 

CENTB2  CHECKS  ENUMERATION  TYPES  UP  TO  2000  ELEMENTS 

Procedure  Centb2  consists  of  35  lines  of  Ada  code  which  rely  on  package  compp  for  the  defini¬ 
tion  of  several  enumeration  types.  The  compilation  of  Centb2  requires  only  49.9  seconds  of  wall 
dock  time.  However,  this  must  be  adjusted  for  the  compilation  time  needed  for  package 
compp — 1710.2  seconds.  Package  compp  consists  of  the  definition  of  four  types.  The  four 
types  each  enumerate  500,  1000,  1500,  and  2000  elements.  Compp  is  dearly  designed  to 
stress  a  compiler’s  ability  to  deal  with  the  individual  language  .feature  of  enumerated  types.  If  the 
time  to  compile  Centb2  and  compp  is  discarded,  the  Maximum  for  elapsed  time  for  the  Norma¬ 
tive  Capacity  Tests  is  258.0  seconds,  which  falls  between  the  observed  maximum  for  the  Norma¬ 
tive  Capacity  Tests  for  DEC  and  VADS.  It  was  due  to  non-benchmark  style  programs  such  as 
Centb2  that  compilation  time  from  ASCII  text  files  was  considered  only  on  the  28  Optional  Algo¬ 
rithms. 

When  compiling  from  ASCII  text  files,  the  Rational  compiler  was  1.2  times  slower  than 
VMSA/AXSet  and  Unix/VADS  in  terms  of  elapsed  time,  across  28  benchmark  style  programs 
from  the  ACEC  suite.  This  compilation  time  indudes  parsing  and  "pretty-printing,"  as  well  as 
machine  code  production.  This  result  is  significant  to  the  porting  of  large  Ada  systems  to  be 
maintained  on  the  Rational  Environment.  The  initial  compilation  of  such  a  system  may  take 
slightly  longer  than  would  be  expeded  for  the  other  evaluated  APSEs. 
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The  instrumentation  results  represent  the  time  to  execute  the  body  of  the  Ada  programs  in  the 
ACEC  suite,  excluding  time  required  for  elaboration.  The  execution  of  the  programs  on  the 
Rational  Environment  was  on  the  average  faster  than  the  execution  times  seen  on  DEC  and 
VADS.  This  speed  advantage  may  be  attributed  to  the  architecture  of  the  R1000,  which  was 
designed  to  accommodate  Ada. 

The  runtime  results  represent  the  time  to  elaborate  and  execute  the  body  of  the  Ada  programs  in 
the  ACEC  suite.  Here  again,  the  Rational  Environment  was  faster  than  DEC  and  VADS  in  terms 
of  elapsed  time.  The  speed  advantage  was  not  as  great  as  that  shown  by  the  instrumentation 
results. 

When  UlAda,  MedAda,  and  BIgAda  are  in  coded  state  on  the  Rational  Environment,  they  re¬ 
quire  more  space  than  the  same  executable  images  produced  by  Verdix  Ada  running  on  a 
MicroVAX  II  with  ULTRIX  1 .2.  However,  when  program  library  support  is  taken  into  account,  the 
Rational  Environment  requires  less  space  than  Verdix  Ada  and  VADS  5.  The  Rational  Environ¬ 
ment  coded  state  programs  require  slightly  less  storage  space  than  the  Alsys  3.2  compiler¬ 
generated  executable  images.  The  space  required  for  the  coded  state  programs  and  Rational 
Environment  directories  is  much  less  than  the  space  required  by  the  Alsys  3.2  compiler  program 
library.  The  Rational  Environment  maintains  program  library  information  in  its  directory  structure. 
It  is  not  attempting  to  layer  Ada  program  libraries  on  top  of  an  external  operating  system  and 
capitalizes  on  this  advantage. 
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7.  Cross  Environment  Performance  Comparison 

The  following  presents  questions  from  each  experiment  category,  with  a  summary  of  answers 
from  previous  Ada  environment  evaluations  and  the  Rational  Environment  evaluation.  Each 
question  is  labeled  by  the  question’s  number  and  the  experiment  section  in  which  it  appeared. 

•  Configuration  Management  and  Versions  Control  -  CM 

•  System  Management  -  SM 

•  Design  and  Development  -  DD 

The  numeric  results  of  the  cross-environment  performance  comparison  show  that  the  Rational 
Environment  is  a  highly  interactive  Ada  development  environment.  Most  commonly  used  com¬ 
mands  have  a  quick  system  response,  often  an  elapsed  time  of  under  two  seconds.  Disk  utili¬ 
zation  for  Ada  units  and  directories  is  on  par  with  the  other  environments  evaluated. 

The  first  value  presented  (VMS/ALS)  is  from  an  evaluation  of  the  SofTech  Ada  Language  System 
Version  3.0  developed  by  the  Army  and  designed  to  be  retargetable  and  rehostable.  The  ALS  is 
hosted  on  DEC’S  VMS  operating  system  (Version  4.2  of  MicroVMS)  and  was  run  on  a  hardware 
configuration  consisting  of  a  MicroVAX  II  with  9  megabytes  of  main  memory  and  disk  space 
consisting  of  three  RD53  disk  drives  (213  megabytes). 

The  second  value  presented  (VMSA/AXSet)  is  from  an  evaluation  of  the  DEC  product  VAX  Ada 
(Version  1 .2)  and  five  additional  tools  collectively  referred  to  as  VAXSet.  VAX  Ada  and  VAXSet 
were  run  on  Version  4.2  of  MicroVMS.  The  hardware  consisted  of  a  MicroVAX  II  with  6  mega¬ 
bytes  of  main  memory  and  102  megabytes  of  disk  space  (one  31  megabyte  RD52  disk  drive  and 
one  71  megabyte  RD53  drive). 

The  third  value  presented  (UnixA^ADS)  is  from  an  evaluation  of  the  Verdix  Ada  Development 
System  (VADS,  Version  5.1)  running  on  ULTRIX,  DEC’S  version  of  Unix  (Version  1.2).  The  tests 
were  run  on  a  MicroVAX  II  configured  with  6  megabytes  of  memory  and  202  megabytes  of  disk 
space  (one  31  megabyte  RD52  drive  and  one  171  megabyte  Fujitsu  drive). 

The  fourth  value  presented  is  from  the  Rational  Environment  Evaluation  and  labeled  "Rational." 
The  Rational  equipment  used  is  described  in  the  introduction  to  this  report. 

VMS/ALS  VMS/VAXSet  UnixA/ADS  Rational 


CM1.2  Elapsed  time  for  performing  a  system  build  operation. 

1937.65  a*c  205.04  169.35  43.50  (aourc*  ->  codad) 

85.64  (cod«d  *•>  loaded) 


CM1.7  Elapsed  time  for  creating  a  CM  file  element. 

13.64  sao  5.61  1.42  2.13 

«lza:  512  byta«  (ava.)512  (ava.)225  3072  bytaa 


CM1.8  Elapsed  time  for  performing  baseline  operation. 

Initial  212.93  aac  90.23  42.95  175.85  (all  aubayatama) 
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B02 

225.41 

92.41 

45.45 

41.15  (only  VT) 

B03 

226.3 

95.10 

45.10 

no  ralaaaa  naadad 

B04 

223.55 

95.33 

46.55 

38.13  (only  SM) 

va.o 

207.15 

101.45 

47.05 

201.51  (all  atibayatama) 

NOTE:  in  config-only  mod«: 
42 . 86  m%G  to  all 

0ub«y0tama 


CM1.9  Flifts  since  Increase  caused  by  baseline  Inclusion. 

no  incraasa  nagligibla  90  bytas 


100, 640  to  ralaasa  SM 
483,609  to  ralaaaa  all  sxibsystfl 
NOTE:  in  config  only  moda: 
51,853  to  ralaasa  all  0ubay0t« 


CM1.22  Eiepsed  time  for  fetching  e  CM  element. 

(non -variant) 


14.46  aac 

4.46 

0.82 

1.37  (chack  out  command) 

CM1.23  Elapsed  time  for  creating  a  variant  of  a  CM  alamant 

aia^Ada  26.45  aac 

12.06 

4.23 

1.00 

vt_body  48.28 

12.38 

4.10 

1.12 

vn_apac_Ada 

48.81 

12.25 

4.40 

1.10 

vm_body_Ada 

48.13 

12.23 

3.55 

1.16 

CM1.24  Eiepsed  time  for  fetching  e  variant  of  a  CM  element 

aiJa^Ada  28.27  aac 

4.95 

0.98 

not  applicabla 

vt_body_Ada 

(aaa  CM1.23) 

28.47 

5.26 

0.90 

N  N 

vm^apao^Xda 

27.79 

4.91 

0.90 

N  M 

vni_body_Ada 

28.52 

5.05 

0.95 

N  N 

CM1.25  Eiepsed  time  for  reserving  e 

verlent  of  a  CM  element 

aiin_Ada  14 . 19  aac 

5.60 

1.56 

not  applicabla 

vt_jDody_Ada 

(aaa  CM1.26) 

15.75 

5.56 

2.00 

N  H 

vm_apac_Ada 

15.66 

5.54 

1.95 

It  N 

vm_body_Ada 

14.93 

5.53 

1.25 

It  M 

CM1.26  Eiepsed  time  for  replecing  e 

varlent  of  e  CM  eiment 

aim_Ada  19.61  aac 

6.54 

3.85 

0.96  (chack  in  command) 

vt  body  Ada 

19.23 

6.75 

2.65 

1.04 

vm_apac_Ada 

19.03 

6.63 

3.85 

1.03 

vm  body_Ada 

19.38 

6.69 

2.70 

1.05 

CM1.27  File  size  Increase  caused  by 

successive  version. 

100% 

majority 

aiza  of  changa 

+  or  -  changa 

no  changa  107  bytaa 

loga  and  daltaa 

aoma:  1  block 

atorad  in  Ik  bytaa 

chunka  in  configuration 


160 


CMU/SEI-88-TR-21 


dAtaba«« 


CM1.28  File  size  Increase  caused  by  variant  version. 


100% 

majority: 

(ava) 

Maka_Path/  with  tokans 

or  -  changa 

no  changa 

111  bytas 

s ava rad,  for  variant 

soma:  1  block 

varsions  of  main: 

sm  tastar  77518  bytas 
cli  tastar  77519  bytas 
vt^tastar  77516  bytas 

CM1.40  Elapsed  time  of  merging  variant  versions  of  a  CM  element. 


main.  Ada  N/A 

12.54  sac 

4.25 

6.38  sac  (avaraga) 

vt  body. Ada 

N/A 

12.93 

3.75 

no  marga  naadad 

vm^spac .  Ada 

N/A 

13.35 

3.75 

no  marga  naadad 

Vhi  body. Ada 

N/A 

3.69  sac 

3.03 

Not  Supportad 

12.91 

3.70 

no  marga 

naadad 

CM1.41  File  size  Increase  caused  by  merge 

N/A  majority: 

no  changa 
soma:  1  block 

1  operation. 

(ava) 

126  bytas 

soma  margas  not  naadad 
for  main. Ada: 

1st  marg*  2572  byta  incraasa 
2nd  paarga  5078  byta  incraasa 
3rd  marga  6358  byta  incraasa 


total  14008  byta  for 

marglng  variant  back  into 
main 


CM1.45  Elapsed  time  of  reserving  a  CM  element. 

(non -variant)  (non-variant)  (non-variant) 

14.21  sac  5.78  0.82  not  applicabla 

CM1.46  Elapsed  time  of  replacing  a  CM  element. 

(non -variant)  (non -variant)  (non -variant) 

19.36  sac  6.94  2.70  not  applicabla 


CM2.2  Elapsed  time  for  displaying  history  Information  for  a  CM  element. 

not  diractly  supportad  0.33  sac  3.55  33.03  for  all  units 

(approx.  2  sac  par  unit) 


CM2.4  Elapsed  time  for  rebuilding  an  earlier  baseline  system. 

3656.89  sac  325.22  188.15 


(from  config.  only  status) 
for  build  133.81  sac 
for  racompila 

24.10  sac 


TOTAL:  157.91  sac 


CM2.8  Elapsed  time  for  deleting  a  CM  element. 
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not  parformad  5.44  aac  N/A 

(making  uncontrollad) 

1.71  aac 

SM2.2  Elepsed  time  for  creating  e  user  account  group. 

3.52  aac  3.44  5.75 

2.49 

SM2.3  File  size  Increase  caused  by  creating  user  account  group. 

majority:  aama  aa  10  bytaa 

no  changa  VMS/ALS  (aiza  of  group 

aoma:  pradaflnad  nama) 

chunka  (ag.  3 

blocka) 

1  byta 
(othar  coata 
could  not  ba 
maaaurad) 

SM2.5  Elepsed  time  for  creating  e  new  user  account 

3.20  aao  3.05  20.20 

6.48 

SM2.6  File  size  Increase  caused  by  creating  a  new  user  account. 

majority:  aama  aa  56  bytaa 

no  changa  VMS/ALS  (aiza  of  naw 

aoiaa:  pradaflnad  uaar  nama  and 

chunka  (ag.  3  full  nama) 

block# ) 

7473  bytaa 
(aiza  of  as^ty  homa 
world) 

SM2.12  Elapsed  time  for  adding  e  user  account  to  a  user  group. 

3.22  aac  3.18  includad  in  SM2.5 

0 . 07  aac 

SM2.13  File  size  Increase  caused  by  adding  a  user  account  to  e  user  group. 

majority:  mmmm  a«  5  bytas  2  bytaa 

no  changa  VMS /US  (ona  byta  mora  (othar  ooata 

aoma:  pradaflnad  than  aixa  of  uaar  could  not  ba 

chunXa  (ag.  3  nama  balng  addad)  maaaurad) 

bloclca) 

SM2.16  Elapsed  time  for  copying  old  account  characteristics  Into  a  new  account. 


3.79  aac  3.74  Not  Support ad 

tima  to  axacuta  command 

that  craataa  a  uaar 

with  aoma  dafault 
charactariatica :  1.77  aac 

SM2.17  File  size  Increase  ceused  by  copying  old  account  Information  Into  new  account 

majority:  sama  aa  N/A  7473  bytaa 


no  changa  VMS/ALS 

aoma:  pradaflnad 
chunSca  (ag.  3 
block# ) 

(ampty  homa  world) 

SM2.20  Elepsed  time  for  dlsebllng  logins  for  e  user  eccount. 

N/A  N/A  N/A 

1.77  aac 

SM2.24  Elapsed  time  for  displaying  user  eccount  cherecterlstlcs. 

2.64  aac  3.11  0.33 

(diaplay  group) 

0.03  aac 

SM2.27  Elapsed  time  for  modifying  a  user  account’s  characteristics. 
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2.84  2.75  Not  Supported  0.03  (change  password) 

SM2.34  Elapsed  time  for  removing  a  user  account  from  a  user  group. 

3.69  sac  3.03  Not  Supportad  0.11  sac 

SM2.35  File  size  decrease  caused  by  removing  a  user  account  to  a  user  group. 

no  dacraasa  no  dacraasa  dacraasa  by  langth  1  byta  dacraasa 

of  usar  nama  +  1 
byta 


SM2.38  Elapsed  time  for  deleting  a  user  account. 

3.19  sac  3.03  15.80  dalata  accass ;  1.81  sac 

dalata  hozna  world: 

1.10  sac 


SM2.39  File  size  decrease  caused  by  deleting  a  new  user  account. 


no  dacraasa 


no  dacraasa  55  bytas 

(siza  of  usar  nama 
and  full  nama) 


7556  bytas 


DD6  What  are  the  CPU  and  clock  times  for  creating  a  program  library? 

Elapsad: 

17  min  17  sac  13.00  sac  3.2  sao  1.73  sac 

CPO:  12  min  26  sac  2.85  sao  0.1  sac  0.70  sac 

DD7  What  are  the  space  utilization  ramifications  of  creating  a  program  library? 

1  block  115  blocks  1.3  blocks  14.5  blocks 

(ia  512  bytas)  (ia  690  bytas)  (ia  7425  bytas) 

DD17  What  are  the  CPU  and  elapsed  times  for  translating  a  compilation  unit  Into  a  specified  program 
library? 

Vact  o  r_Man  agaman t  Spac : 

Elapsad:  (sourca  to  codad) 


1  min  19  sac 

11.38 

sac 

9.0 

sac 

5.52 

sac 

CPO:  41  sac 

4.11 

sac 

1.0 

sac 

2.48 

sac 

Matrix  Managamant  Spac: 

Elapsad : 

1  min  27  sac 

11.91 

sac 

6.9 

sac 

3.00 

sac 

CPO:  48  sac 

5.94 

sao 

0.7 

sac 

1.37 

sac 

DD18  What  are  the  space  utilization  ramifications  of  translating  a  compilation  unit  Into  a  specified 
program  library? 


Vaot  or^Managamant 
1024  bytas 

Vac t o  r^Man agaman t 
81,920  bytas 


Sourca : 

1024  bytas 
(optional) 
Ob j act  Coda: 

4608  bytas 


6751  bytas 


Ha  t  r  i  x^Managaman  t 
1024  bytas 

Matrix  Managamant 
65, 536  bytas 


Sourca: 

1024  bytas 
(optional) 
Ob j act  Coda: 

5120  bytas 


(not  availabla) 


library  spaca:  125  bytas 
objact  siza:  13281  bytas 


library  spaca:  125  bytas 
objact  siza:  11365  bytas 


DD22  What  are  the  CPU  and  elapsed  times  for  translating  a  compilation  unit  Into  a  specified  program 
library? 
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15.11  mmc 
8 . 63  mmc 


12 . 2 


(source  to  codod) 
6.13  B%c 
3.09 


Voctor_Mana9«n*nt  body: 
Elapsod: 

1  min  49  sac 
CPU:  1  min  6  sac 


4 . 9  sac 


DD26  What  are  the  CPU  and  elapsed  times  necessary  for  creating  an  executable  module? 

Elapsad: 

7  min  45  sac  23.86  sac  25.1  sac  N/A 

CPU:  4  min  50  sac  1.53  sac  10.5  sac 


DD27  What  are  the  space  utilization  ramifications  of  creating  an  executable  module? 

an  additional 

151,040  bytas  30,208  bytas  68,127  bytas  N/A 

DD32  What  are  the  space  utilization  ramifications  of  browsing  a  compilation  unit? 

no  incraasa  no  incraasa  browsing  not  no  incraasa 

support ad 
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Appendix  A:  Size  and  Time  Reporting  Procedures 

The  following  procedures  were  used  to  obtain  the  instrumentation  data  for  the  Configuration 
ManagementA/ersion  Control  Experiments  and  the  System  Management  Experiments.  Each 
routine  is  followed  by  a  short  explanation  of  its  use. 


A.1.  Specification  Record_Size’Spec 

Procedure  Record_Si2e  has  three  parameters:  Message,  Object,  and  Recursive.  Message 
can  be  any  string  which  will  be  reprinted  with  the  size  figures  and  should  be  used  to  annotate  the 
resulting  log.  Object  is  the  object  whose  disk  utilization  in  being  measured  and  reported. 
Recursive  indicates  whether  subobjects  of  the  Unit  should  be  included  in  the  size  measurement. 
If  Recursive  is  True,  then  the  object's  space  utilization  plus  sub-objects'  space  utilization  will  be 
reported.  If  Recursive  is  false,  then  only  the  space  utilization  of  that  object  itself  will  be  reported. 

proo*d.urtt  Record  Six*  Spring  "**; 

Obj*ct«  :  String 

R*ourxiv«  :  Boolean  Tru*) ; 
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A.2.  Procedure  Record_Si2e’Body 

with  Dlr«ctory_Tool«/  lo; 

proc«dur«  R*cord_Slz«  :  String  :m  "**; 

Object#  :  String  :« 

R*cair«lv«  :  Boolean  Tru«)  1« 

packag*  Dt  r«nain«s  Dlr^ctory^Toolz; 

pac)^g«  Stat  ranaznaa  Dlractory_Toola  .Statlatlca; 

Orig_Ob j /  Ob j  :  Dt . Qb jact . Bandla; 

Itar  :  Dt .Objact . Itarator; 

Suzn_Qb jact_Slza,  Sui&_Total_Slza  :  Long_Intagar  0; 

Anawar2  :  String  (1  ..  10); 
bagln 

If  Racuralva  than 

Itar  Dt. Naming. Raaolut Ion  (Objacta  fi  "??"}; 

alaa 

Itar  :«■  Dt. Naming. Raaolut Ion  (Objacta); 
and  If; 

Orlg_Obj  :■  Dt .Ob jact . Valua  (Itar); 
whlla  not  Dt .Ob jact .Dona  (Itar)  loop 
Obj  Dt. Ob jact. Valua  (Itar); 

SumjOb jact_Slza  :■  Sum_Total_Siza  +  Stat .Ob jact_Siza  (Obj)  /  8; 
Sum_Total_Slza  :m  Sum_Total_Slza  Stat . Total_Slza  (Obj)  /  8; 

Dt .Objact.Naxt  (Itar) ; 
and  loop; 

If  Racuralva  than 

Anawar2  "avarythlng”; 

alaa 

Anawar2  "Itaalf 

and  If; 
daclara 

Anawarl  :  oonatant  String  Dt . Naming . Slmpla^Nama  (Orlg^Obj)  &  "  *; 

AnawarS  :  conatant  String 

”  objact^alza  ■>  "  &  Long_Intagar' Imaga  (Sum^Ob  jact^Slza)  fi 
",  total_alza  ■>  "  £  Z*ong_Intagar' Imaga  (Sum^Total^Slza)  ; 

bagln 

lo .  Put_Llna  (Maa  a  aga ) ; 

Io.Rut_Llna  (Anawarl  fi  Anawar2  fi  AnawarS); 

and; 

and  Racord  Slza; 


A.3.  Using  Record_Size 

Record_Slze’Spec  and  Record_Slze’Body  can  be  placed  in  the  experimenters  home  directory 
and  compiled  and  executed  from  the  home  directory.  To  execute  the  procedure: 

Open  a  command  window 
<Create  Command> 

Enter 

Record__Size 

<Con^lt> 

Record^Size (Message  =>  " ”  , 

Objects  => 

Recursive  =>  True) ; 

Supply  a  message,  if  desired,  to  annotate  the  log  and  provide  the  full  pathname  to  the  object  and 
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the  object  named  for  the  value  of  Objects.  If  a  measurement  of  only  the  object  and  not  its 
sub-objects  is  desired,  change  the  value  of  Recursive  to  False. 

Execute  the  command 
<Proinot> 

The  message,  followed  by  the  object  name  and  its  space  utilization  requirements  in  bytes,  is 
reported  to  the  standard  output  window. 


A.4.  Specification  Timeit’Spec 

Procedure  TImeit  requires  no  parameters. 

procAdur*  TixMit; 


A.5.  Procedure  Timeit’Body 

with  Conpilation,  Ctavo,  T*xt_Io,  Tiffla_Utiliti*0,  Sy«taa_Otiliti*s; 
procadur*  Timait  is 

variablas  for  timing 

Bagin_Tixaa  :  Duration  0.0; 

£nd_Tima  :  Duration  0.0; 

Bagin_Cpu_Tiffla  :  Duration  0.0; 

End_Cpu_Tima  :  Duration  :■  0.0; 

output  for  timings 

packaga  Duration_Io  is  naw  Taxt^Io .Fixad_Io  (Duration); 


bagin 

Taxt_Io .  Pu t_Lina  ( "  CLOCK  CPO  )  ; 

—  racord  tha  clock  tima  sinca  systam  boot  £  cpu  tima  sinca  job  start 
Bagin_Tijna  :m  Systam^Otilitias  .Elapsad; 

Bagin^Cpu^Tima  :m  Systam^Otilitias . Cpu; 

—  PLACE  COMMAND  TO  TIME  EEPE: 

Chive. Ralaasa  (From^Working^Viaw  «> 

**  1  usars  .  QXpQfimontQr.  cm_axpariziiant .  vt .  rav2_working'' , 

Ral aas  a_Nama  »>  " <AUTO_GENERATE> " , 

Laval  0, 

Viaws_To_Inport  ■>  *»<INHERIT_IMPORTS>" , 

Craata  Configuration  Only  «>  Falsa, 

Con^ila_Tha_Viaw  ■>  Trua, 

Goal  Compilation . Codad, 

Commants  b>  " “ , 

Wo  rk^Or da  r  — >  **  <DErA0LT>  “  , 

Voluma  0, 

Rasponsa  ->  "<PROFILE>'* )  ; 

End_Cpu_Tima  : »  Sys t am_Ot i  1  i t ia s .  Cpu ; 

End_Tima  :m  Systam^Otilitias .Elapsad; 


Duration_Io . Put  (End_Tima  -  Bagin_Tima,  4,  2,  0); 
Taxt_Io.Put  ("  "); 

Duration^Io .Put  (End^Cpu^Tima  -  Bagin^Cpu^Tima,  4,  2,  0)  ; 
and  Timait; 
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A.6.  Using  Timeit 

Procedure  Timeit  is  shown  here  set  up  to  time  the  Cmvc.Reiease  command.  The  procedure 
Timeit  can  be  placed  in  the  expenmentefs  home  directory  and  compiled.  In  order  to  time  any 
command  or  series  of  commands,  the  Timeit  procedure  can  be  modified  using  the  incremental 
editing  possible  with  the  Rational  Environment.  Following  is  a  transcript  to  change  the  Timeit 
procedure  after  it  has  been  promoted  to  coded  state  in  the  experimenter's  home  directory. 

Make  Tixnelt '  body  the  current  context . 

<Znstall  nnit> 

Select  the  statement  appearing  below 
the  comment . 

PLACE  COMMAND  TO  TIME  HERE; 

<Edit> 

An  edit  window  will  open;  replace 
the  Cmvc . Release  command  with 
the  new  command  to  be  timed;  no 
parameters  need  be  typed  at  this 
point . 

<Format> 

Select  the  new  command. 

<Complt> 

The  parameters  and  their  default  values  will  be  supplied.  Change  the  default  values  as  needed. 
If  there  is  an  error  message  "No  completion  for  X,"  where  X  is  the  name  of  the  command  in¬ 
serted,  its  package  must  be  added  to  the  with  clause  at  the  beginning  of  the  program.  Do  this  by 
moving  the  cursor  to  the  line  after  the  existing  with  clause.  Type  <Object>  I,  then  in  the  edit 
window,  type  "With  PACKAGE,"  where  PACKAGE  is  the  name  of  the  package  in  which  the 
command  is  defined.  Type  <Promot>  to  return  to  the  edit  window  containing  the  command  to  be 
completed,  and  retype  <Complt>,  supplying  any  needed  parameters. 

Place  the  contents  of  the  edit  window 
back  into  the  body. 

<Promot> 

Return  the  entire  body  to  coded 
state . 

<Promot> 

The  procedure  Timeit  can  then  be  executed  from  a  command  window.  The  results  of  the  timeit 
command,  and  any  messages  from  the  timed  procedure,  will  appear  in  the  standard  output  win¬ 
dow. 
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Appendix  B:  Design  and  Development  Instrumentation 
Procedures 


The  library  creation,  file  copy,  and  Ada  object  promotion  commands  have  been  incorporated  into 
the  following  procedures  that  measure  them  by  recording  time  and  disk  space  utilization.  Section 
B.12  describes  how  they  can  be  used  when  executing  the  experiment  instantiation  in  Chapter  4. 
In  the  following  program  segments,  experimenter  is  used  in  directory  names  to  indicate  where  a 
user  may  insert  his  own  user  name. 


B.1.  Package  Kluge_Stuff 

The  package  Kluge_Stuff  defines  some  common  types  and  constants.  The  type 
Selection_Methods  allows  a  user  to  perform  an  operation  on  an  object  that  is  either  selected  by 
having  the  cursor  in  its  image  or  by  selecting  the  object  (<Object>  Left  Arrow)  in  its  enclosing 
directory.  It  also  sets  up  a  file  to  serve  as  a  place  to  store  timing  information  taken  at  the 
beginning  of  an  operation  to  be  used  with  timing  information  taken  at  the  end  of  an  operation. 

pacJcag*  lQug*_Stuff 

typ«  S*1  Act  ion_M«t hods  (Cur«or_Xn_Izxiag«, 

Highlight_In_Dir«ctory) ; 


Th«_Nam«  :  constant  String  ;«■ 

"  1  Oaars  .  QXperiment&r.  axp_^lib .  inf  ila  ** ; 

typa  Info  is 
racord 

Salaction_Mathod  :  Kluga_Stuf f . Salaction_Mathods ; 
Library_Siza_^Bafora_Proa»otion  :  Xntagar; 
and  racord; 

and  lQuga__Stuff ; 


B.2.  Specification  Timed_Code’Spec 

The  procedure  to  initiate  and  time  the  compilation  of  an  Ada  unit  requires  no  parameters  as 
indicated  by  its  one  line  specification. 

p  rocadura  T  imad_^Coda ; 


B.3.  Procedure  Timed_Code’Body 

Package  Tlmed_Code  collects  the  size  of  the  enclosing  library  and  the  time  required  to  compile 
an  Ada  Object. 
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—  Ada/  Ada^Qb jact_£ditor/  Common  and  Ob jact__Edltor  ara  Rational 
— >  Environmant  packagaa . 

with  CosoBkon/  Diract_ZO/  lQuga_Stuf f  /  Siza_Of/  Ta3ct_ZO/  Timing_Log/ 
Timing/  Ada,  Ada_Ob jact_Editor/  Ob jact_Editor; 

procadura  Timad^Coda  is 

Library's iza^Bafora^Promot ion  :  Zntagar  :»  0; 

—  initializad  by  unit  nama  function 

Salaction^Mathod  : 

lU-uga^Stuf  f .  Salaction_Mathoda ; 


—  Tha  following  daclarationa  ara  raquirad  to  paaa  information 
ganaratad  by  thia  procadura  to 

—  Finiah^Coding^Znatrumantation.  Thia  kluga  ia  nacaaaitatad 

—  by  a  bug  in  tha  Rational  Environmant  that  pravanta  timad 

—  coda  from  raading  library  aiza  or  unit  aiza  aftar  promoting 

—  a  unit. 

packaga  Znfo^Zo  ia  naw  Diract_Zo  (Kluga_Stuf  f .  Znfo)  ; 

Tha^Fila  :  Znf o_Zo . rila_Typa ; 

Tha^Znfo  ;  Kluga_Stuf f . Znf o ; 


— >  Tha  Unit^Nama  function  haa  tha  aida  affact  of  aatting 

—  Salaction^Mathod. 

—  Salaction^Mathod  in  turn  ia  uaad  to  datazmina  how  tha 

—  library  contaxt  of  tha  unit  baing  promotad  ia  rafarancad. 

Zf  curaor  ia  in  imaga  than  tha  ancloaing  contaxt  apacial 

—  charactar  ia  uaad.  Zf  tha  unit  it  highlight ad  than  tha 

—  currant  contaxt  atring  **[]”  ia  uaad. 

—  Tha  library  aiza  function  dapanda  on  tha  aida  affact  of 

—  unit^nama  which  muat  ba  callad  bafora  library_aiza . 


function  0nit_17ama  ratum  String  ia 

packaga  Aoa  ranamaa  Ada^Ob jact^Editor; 
packaga  Oa  ranamaa  Ob jact_Editor; 
bagin 

if  Aoa .  Xmaga^lJama  ^  “###0n3cnown###''  than 
Salact ion_Mathod  : « 

Kluga_Stuf f . Highlight_Zn_Diractory ; 
ratum  Oa .  Gat_17ama  (Oa .  Sal  act  ion)  ; 

alaa 

Salaction  Mathod  Rluga  Stuff. Curaor  Zn  Zmaga; 
ratum  Aoa. Zmaga  Nama; 
and  if; 

and  0nit  Nama; 


function  Library_Siza  ratum  Natural  ia 
bagin 

caaa  Salact ion^Mat hod  ia 

whan  Kluga^Stuf  f  .Curaor^Zn^Zmaga  ai> 
ratum  SizajOf  (»‘^«)  • 

whan  Rluga^Stuf f . Bighlight_Zn^Oiractory  «> 
ratum  SizajOf  ("[]"); 

and  caaa; 

and  Library^Siza; 
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b«gin 


Timing  Log.J^>p«nd  Lin*; 

Timing^Log. J^p*nd^Lin*  ("Coding  unit:  "  C  Unit_Nam*}  ; 
Libr*r7_Siz*_B*for*__Promotion  Libr*ry^Siz*; 

Tijning_Log .  i^p*nd_Lin* 

("Library  aiz*:  "  C  Int*g*r' Imag* 

(Library_Siza_Bafora_Promotion)  fi 

"  bafora  promotion.")/ 


Timing . Raaat; 

Ada . Coda_Unit ; 

Timing  Log.Appand  Lina 


Timing_Log , Cloaa_Log; 


Cloc)c  tima;  "  C  Timing. Wall_Tima  C 
CPU  tima:"  C  Timing. Cpu); 


Stora  data  that  will  ba  picbad  up  by 
O'-  finiah  coding  inatrumantation . 

Tha_Inf o . Salaction_Mathod  Salaction_Mathod; 

Tha^Inf o .  Llbrary_Siza_Baf ora^Proinotion  :  v 
Lib  r  ary_S  i  z  a_B  a  f  o  ra_P  romo  t  i  o  n ; 

Inf o^Io . Craata 

(FI la  *>  Tha_Fila, 

Moda  ■>  Info^Io.Out__rila, 

Nama  b>  lCluga_Stuf  f .  Tha_Nama, 

Form  ■>  " " ) ; 

Inf  o_Io . Wrlta 

(Tha_Fila,  Tha_Info) ; 

Inf  o^Io  .  Cloaa  (Tha_^Flla)  ; 

and  Timad  Coda; 


B.4.  Specification  Finish_CodingJnstrumentation’Spec 

The  package  specification  for  Rnish_CodingJnstrumentation  shows  that  the  body  can  take 
one  parameter.  When  Both  is  set  to  true,  the  size  of  both  the  package  specification  and  body  will 
be  recorded.  The  default  is  false,  which  causes  the  recording  of  the  size  of  just  the  indicated  Ada 
Unit  (either  the  Ada  Unit  is  selected,  or  the  cursor  currently  resides  in  the  Ada  Unit's  image.) 

procadura  Flnlah_Codlng_Inatrumantatlon  (Both  :  In  Boolaan  Falsa) ; 


B.5.  Procedure  Finish_Coding_lnstrumentation’Body 

An  explanation  of  Rnish_Coding_instrumentation  can  be  found  in  the  comments  in  the  code. 


CMU/SEi-88-TR-21 


171 


with  Ada,  Ada_j^ jact^Editor,  Coznnon,  Diract^Io,  Kluga^Stuff, 

Qb  jact_£ditor,  Siz«_Of,  Taxt_IO/  Timing,  Timing_Log; 

—  Thic  procadura  log*  tho  post  promotion  sizo  of  oithor  a  spac,  a 

—  body,  or  both.  Both  should  ba  sat  to  trua  only  whan  compiling 

—  a  main  procadura  body  for  which  a  spac  doas  not  axist.  In  this 

—  casa  tha  systam  automatically  ganaratas  a  spac,  which  consumas 

—  objact  and  library  spaca.  Tha  program  spac  or  body  is  indicatad  by 

—  aithar  tha  cursor' s  baing  prasant  in  an  imaga  of  tha  spac  or  body,  or  by 
tha  program  spac  or  body  salactad  with  tha  cursor  basida,  in  its  parant 

—  diractory  listing.  Tha  parant  diractory  listing  must  ba  in  standard  format, 

—  that  is,  with  (proc_J?ody)  or  (proc^spac)  indicatad. 

procadura  Finish^Coding^Instrumantation  (Both  :  in  Boolaan  Falsa)  is 

Tha  following  daclarations  ara  raquirad  to  raad  information 

—  ganaratad  by  Timad^Coda.  This  kluga  is  nacassitatad  by  a 

—  bug  in  tha  Rational  Environmant  that  pravants  library  and 

—  objact  sizas  from  baing  raad  aftar  promotion  by  a  procadura 

—  that  promotas  an  objact. 

packaga  Info^Io  is  naw  Diract_Io  (Kluga_Stuff .Info) ; 

Tha_Fila  ;  Info^Io.Fila^Typa;  — Nama  of  fila  containing  information 

Tha_Info  :  Kluga_Stuff  .Info;  — Racord  that  holds  information 

—  Tha  following  ara  maasurad  by  this  procadura 
Library^Siza^Af tar__Promotion,  Unit_Siza^Aftar__Promotion  : 

Intagar  0; 

—  Functions  nnit__Nama  and  Library__Siza  ara  clonad  from 
—  Timad^Coda . 

function  nnit__Nama  ratum  String  is 

— Ratums  tha  nama  of  tha  unit  that  was  promotad  and  is  to  ba  maasurad. 
bagin 

Procadura  Timad_Coda  datarminad  how  tha  usar  was  indicating  tha 
—  ooda  to  ba  promotad,  and  raoordad  it. 
casa  Tha^Inf o .  Salaotion__Mthod  is 

Whan  tha  coda  is  indicatad  by  tha  cursor' s  baing  in  a  window 
--  containing  tha  f ila' s  izaaga,  than  tha  f ila' s  nama  can  ba 
—  datarminad  by  a  call  to  Imaga_Nama. 
whan  Kluga^Stuff  .Cursor^In^Imaga  k> 

ratum  Ada_j0b  jact_£ditor .  Imaga__Nama ; 

—  Whan  tha  coda  is  indicatad  by  baing  highlight ad  in  tha 
--  diractory  listing,  than  tha  fila's  nama  can  ba  datarminad 
by  a  call  to  Gat_Naffla. 
whan  Kluga_Stuff  .Highlight_In_Diractory  «> 

ratum  Ob  jact_Editor  .Gat__Nama  (Ob  jact_JCditor .  Salaction) ; 

and  casa; 

and  nnit__Nama; 

function  Library^Siza  ratum  Natural  is 

—  Datarmina  tha  siza  of  tha  objact' s  parant  library, 
bagin 

—  Dapanding  on  how  tha  usar  has  indicatad  tha  objact,  datarmina 
--  tha  siza  of  tha  parant  library. 

casa  Tha^Inf o . SalaGtion_Mathod  is 

whan  Kluga_Stuff  .Cursor_In_Imaga  *> 
ratum  SizajOf  ("'^"); 

whan  IQuga_Stuf f .  Highlight_^In_Diractory  => 
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r*tum  Siz«_Of  (•*[]"); 


•nd  cas*; 

and  Llbrary^Siza; 

—  Unit  siza  is  maasurad  only  aftar  promotion  bacausa  siza  of 

—  objact  ratumad  by  tha  Siza^Of  function  appaars  to  ba 

—  random  if  tha  objact  has  navar  baan  installad. 
function  Unit_Siza  ratum  Natural  is 

--  Maasuras  tha  siza  in  bytas  of  tha  salactad  objact  or  objacts  if  both 
—  a  spac  and  a  body  wara  conpilad. 
bagin 

casa  Tha_Inf o . Salaction^Mathod  is 

whan  Kluga_Stuf f .  Cursor_In_Imaga  ■«> 
if  Both  than 

—  Whan  in  a  body  tha  currant  contaxt  symbol 
”[]"  is  intarpratad  as  rafarancing  tha 
—  spac.  Tha  ixaaga  nama  ratumad  by 
—  Ada^Ob jact_Editor  always  has  a  spac  or  body, 
ratum  Siza^Of  ("[]")  + 

Si  z a_Of  < Ada_Qb  j act_Edi t o r .  Imaga^Nama )  ; 

alsa 

ratum  Siza_Of  (Ada_Ob  jact_Editor .  Imaga_Nama} ; 
and  if; 

--  Whan  tha  objact  is  salactad  by  highlighting  it  in  tha 

—  parant  diractory,  tha  Objact  Editor  only  ratums  a  nama, 

--  it  doas  not  ratum  'spac  or  'body  typas,  which  tha  Siza^Of 
--  function  naads  in  ordar  to  looata  tha  propar  objact  to 

—  maasura.  Tha  taxt  manipulation  balow  ralias  on  tha  diractory 

—  listing  to  ba  in  standard  format,  and  actually  drags  all  of 

—  tha  charactars  off  tha  highlight ad  linas  and  saarchas  for 

—  (proc  body)  or  (proc_spac}  in  ordar  to  gat  tha  propar 

—  maasuramant. 

whan  Kluga_Stuff  .Highlight_In_Diractory  *> 

Tric)cy_Taxt_Manipulation : 
daclara 

Big_String  : 

String  (1  ..  120)  :«  (othars  — >  '  ' ) ; 

--  Will  hold  taxt  grabbad  off  of  highlightad  lina. 
Start^Of_Typa  :  Natural  :■  0;  — holds  location  of 

—  Opan  paran.  of  tha  paran's.  around  tha  objact 
—  typa. 

Body_Salactad  :  Boolaan;  — trua  if  objact  is  a 
—  Packaga  body,  falsa  if  objact  is  a  packaga  spac. 

bagin 


--  Grab  highlightad  taxt  and  stuff  in  Big_String. 
Big^String 

(1  ..  Objact_Editor.Gat_Taxt 

(Ob jact_Editor . Salaction) 'Last)  : « 

Ob  jact^Editor .  Gat^Iaxt  (Ob  jact^Editor .  Salaction)  ; 
— X*ocata  opan  paran.  in  salactad  taxt. 
for  I  in  Big_String'Ranga  loop 
if  Big^String  (I)  «  ' ('  than 
Start_Of_Typa  :  ■  I  / 
axit; 
and  if; 
and  loop; 


—  Find  out  what's  salactad. 
Body^Salactad 
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Big_String 

(St«rt_Of_Typ#  +  1  .  .  Start_Of_Typ«  +  9) 
»  " P  roc_Body " ; 


•nd  caca; 

and  Unit  Siza; 


if  Both  than 

—  Print  out  notica  that  both  a  body  and  spac 
--  ara  baing  maaaurad. 

Ti2iiing_Log .  J^pand_^Lina 

( "BOTH  ' body  and  ' apac  of  ”  £  Unit_Naroa  £ 

*  aizad  and  coxopilation  tixuad**); 
ratum 

SizajOf  (Unit_Nama 

£  "'body")  + 

Siza  Of  (Unit  Kama 


--  Only  aiza  of  aalactad  taxt  ia 
—  daairad/  ba  it  a  body  or  a  apac. 
if  Body_Salactad  than 

—  Print  out  notica  that  juat  a  body  ia 
—  baing  maaaurad. 

Timing_Log .  Appand_Lina 

("ONLY  'body  of  "  £  Unit_Nama  £ 

"  aizad  and  compilation  timad"); 
ratum 

Siza_Of  (Unit_Naxna  £ 

"'body") ; 

alaa 


—  Print  out  notica  that  juat  a  apac  ia 
—  baing  maaaurad. 

Timing_Z(Og .  Appand_Lina 

("ONLY  'apac  of  "  £  Unit_Nama  £ 

"  aizad  and  compilation  timad"); 
ratum 

Siza_jOf  (Unit_Nama  £  "'apac"); 

and  if; 
and  if; 

and  Tric]cy_Taxt_Manipulation; 


bagin 


—  Ratriava  data  atorad  by  Timad_Coda  (aalaction  mathod  and  library 

—  aiza  bafora  promotion  of  tha  objact. 

Info_Io.^an  (Tha_JFila,  Inf o_Io . In_rila, 

Kluga_Stuf f .Tha_Nama) ; 

Info_Zo.Raad  (Tha_Fila,  Tha_Znfo) ; 

Znfo_Zo .Dalata  (Tha_Fila) ; 

—  Obtain  aftar  promotion  data  on  aiza  of  tha  library. 
Library__Siza_Aftar_Promotion  :«i  Library_Siza; 

—  Gat  aiza  of  unit  aftar  promotion. 

Unit_Siza_Aftar_Promotion  :»  Unit_Siza; 

—  Racord  tha  information  in  log  fila. 

Timing_Log.J^pand_Lina  ("Library  Siza  Aftar  Promotion:  "  £ 

Zntagar' Zmaga  (Library_Siza_Aftar_Promotion) )  ; 

Timing_Log.i^pand__Lina  ("Unit  Siza  Aftar  Promotion:  "  £ 

Zntagar' Zmaga  (Unit  Siza  Aftar  Promotion) ) ; 


TimLing_Log .  Jl^pand__Lina 

("Library  apaca  uaad  by  coding  "  £ 
UnitJNama  £ 

"  ia  "  £  Zntagar'  Zmaga 
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(Library_Six«_Aft«r_Pr ©motion  - 
Tho^Info .  Library^Sizo^B«for«_^Promotion)  )  ; 

--  all  dona,  tha  log 
Tiniing_Log .  Clo«a_Log; 

and  Finish_Coding_In«trumantation; 


B.6.  Specification  Timed_Directory’Spec 

The  package  specification  for  Timed_Directory  indicates  that  it  takes  one  parameter,  the  name 
of  the  directory  to  be  created. 

—  Timas  tha  craation  of  a  diractory  and  calculataa  tha  apaca 

—  raquirad  for  tha  nawly  craatad  diractory  and  tha  spaca  uaad  by 

—  its  parant  diractory  to  atora  information  about  it. 

—  Racorda  tha  information  in  fila  daaignatad  by  fila  raad  by 

—  Timing_log .  ratriava_currant_log_nama . 
procadura  Timad^Diractory  (Diractory_Nama  ;  String  :■> 


B.7.  Procedure  Timed_Directory’Body 

The  package  body  nmed_Directory  times  the  creation  of  a  directory.  The  directory  is  created 
as  an  object  in  the  closest  enclosing  context  that  is  either  a  world  or  directory.  It  is  given  the 
name  passed  in  the  Directory_Name  parameter. 
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—  Ada  1«  a  Rational  S^vlronmant  pacAaga  that  u«ad  to  contain  procadura 

—  Ada.Craata_Diractor7.  Ada.Craata_Dlractory  la  now  found  in 

—  fCoomanda . Library .Craata^Dlractory  (LM-222)  for  Oparatlng  Syatazn  Varalon 

—  Dalta. 

--’With  Slza^Of,  Tlmlng^Log,  Timing,  Ada; 
with  Slza_Of,  Tlmlng_Log,  Timing,  Library; 

procadura  Tlmad^Dlractory  (Dlractory^Nama  :  String  *’")  la 

—  Tlmaa  tha  craatlon  of  dlractory  paaaad  aa  quotad  atrlng,  alao 

calculataa  tha  apaca  uaad  by  tha  nawly  craatad  dlractory;  and  tha 
—  apaca  raqulrad  by  Ita  par ant  to  atora  Information  about  It;  It 
--  racorda  tha  Information  In  flla  daalgnatad  by  flla  raad  by 
—  Timing_log .  ratriava_currant_log_nama . 

Slza^Bafora^Craatlon,  —  Slza  of  parant  dlractory  bafora 

—  craatlon  of  raquaatad  dlractory  In  bytaa . 
Slza_Aftar_Craatlon  :  Intagar;  —  Slza  pf  parant  dlractory  aftar  craatlon 

—  of  raquaatad  dlractory  In  bytaa. 


bagln 

—  Tha  atrlng  "[]"  Indlcataa  tha  currant  contaxt,  which  la 
--  tha  library  In  which  tha  dlractory  la  to  ba  craatad. 
Slza^Bafora^Craatlon  Slza^Of  ("[]"); 

--  Sand  blank  llna  to  log  flla. 

Tlmlng^Log .  Appand^Llna ; 

—  Racord  nama  of  dlractory  to  ba  craatad. 

Tlmlng_Log . Appand^Llna  ("Craatlng  dlractory:  " 

£  Dlractory_Nama) ; 

—  Racord  cpu  tlma  and  wall  clock  tlma  bafora  craatlon  of  dlractory 
--  Invokad. 

Timing . Raaat ; 

—  Craata  tha  raquaatad  dlractory. 

Library . Craata^Dlractory  ( Dirac tory_Nama) ; 

--  Calculata  and  racord  tha  CBU  and  Wall  Clock  tlma  alapaad  In  tha 

—  craatlon  of  tha  dlractory  In  aaconda . 

Tlmlng_Log.Appand^Llna  ("Clock  tlma  (aac) :  "  &  Tlmlng.Wall_Tlma  £ 

"  CPU  tlma  (aac):"  £  Timing. Cpu); 

—  Datarmlna  alza  of  parant  dlractory  with  Ita  naw  a\ibdlractory 
—  Information. 

Slza^Aftar^Craatlon  :■  SizajOf  ("[]"); 

—  Datarmlna  alza  of  naw  dlractory  itaalf  and  bytaa  addad  to  parant 

—  dlractory  and  racord. 

Tlmlng_Log . Appand^Llna 

("Dlractory  craatlon  conaumad  " 

£  Intagar' Imaga  ( 

(Slza^Af tar^Craatlon  -  Slza^Bafora^Craatlon)  + 
Slza_Of  (Dlractory_Nama) )  £  "  bytaa."); 

--  Dlractory  craatlon  and  racordlng  flnlahad,  cloaa  tha  log  flla. 
Tlmlng_Log .  Cloaa_Log; 

and  Tlmad_Dlractory; 
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B.8.  Specification  Timed_Worid’Spec 

The  package  specification  for  Tlmed_World  indicates  that  it  takes  one  parameter,  the  name  of 
the  world  to  be  created. 

proc«durtt  Tim«d_WorId  (World^Naxn«  ;  String  *"*); 


B.9.  Procedure  Timed_World’Body 

The  package  body  T1med_Wor1d  times  the  creation  of  a  world.  The  world  is  created  as  an  object 
in  the  closest  enclosing  context  that  is  either  a  world  or  directory.  It  is  given  the  name  passed  in 
the  World_Name  parameter. 


CMU/SEI-e8-TR-21 


177 


—  Ada  is  a  Rational  Environmant  packaga  that  us  ad  to  contain  procadura 

—  Ada.Craata^World.  Ada.Craata^World  is  now  found  in  fCoxmnands  .Library. 

—  Craata_World  (LM-227)  for  Opa rating  Systam  Varsion  Dalta. 

— with  Siza^Of,  Timing^Log,  Timing,  Ada; 
with  Siza_Of,  Timing^Log,  Timing,  Library; 
with  Editor; 


procadura  Timad_World  (World_Nama  :  String  ;«’*")  is 
— >  Timas  tha  craation  of  world  pas sad  in  as  quotad  string;  also 

calculatas  tha  spaca  usad  by  tha  nawly  craatad  world  and  tha  spaca 

—  raquirad  by  its  parant  to  stora  information  about  it;  it 

—  racords  tha  information  in  fila  dasignatad  by  fila  raad  by 

—  Timing_Log .  Ratriava_Currant_Log_Nsma . 

Siza^Baf ora^Craation,  — siza  of  parant  diractory  bafora  craation  of 

— raquastad  world  in  bytas 


S i za^Af t a r_Cr aat i o n 
bagin 


Intagar;  —siza  of  parant  diractory  aftar  craation 
--of  raquastad  world  in  bytas 


—  Tha  string  "[j"  indicatas  tha  currant  contaxt,  which  is 

—  tha  library  in  which  tha  world  is  to  ba  craatad. 
Siza_Bafora_Craation  :»  Siza_Of  ("13"); 


—  Sand  blank  lina  to  log  fila. 
Timing^Log . Appand^Lina ; 


—  Racord  nama  of  world  to  ba  craatad. 

Timing^Log . Appand_Lina  ("Craating  world:  "  £  World_Nama) ; 

—  Racord  CPU  tima  and  wall  clock  tima  bafora  craation  of  world  invokad. 
Timing . Rasat ; 

—  Craata  tha  raquastad  world. 

Library  .Craat a^Wor Id  (WorldJNama)  ; 

—  Calculata  and  racord  tha  CPU  and  wall  clock  tima  alapsad  in  tha 

—  craation  of  tha  world  in  saconds . 

Timing_Log.J^pand_Lina  ("  Clock  tima:  "  fi  Timing . Wall_Tima  £ 

"  CPU  tima;"  £  Timing. Cpu); 

—  Datarmina  siza  of  parant  diractory  with  its  naw  "sub-world"  information. 
Siza_Af tar_Craation  : ■  Siza_Of  ("13")/ 


--  Datarmina  siza  of  naw  world  itsalf  and  bytas  addad  to  parant 
—  diractory  and  racord. 

Timing_Log.J^pand_Lina  ("World  craation  consumad  " 

£  Intagar' Imaga  (  (Siza_^tar_Craation  - 
Siza_Bafora_Craation)  + 


Siza_Of  (World_Nama) )  £  "  bytas."); 

—  World  craation  and  racording  finishad;  closa  tha  log  fila. 

Timing_Log .  Closa_Log; 

and  Timad  World; 
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B.10.  Specification  Sized_Copy’Spec 

The  package  specification  Slzecl_Copy  indicates  that  the  procedure  requires  one  parameter  a 
string  value  for  Unlt_To_Copy  which  indicates  the  Ada  unit  that  is  to  be  copied  in  order  to 
measure  its  size. 

proc*durtt  Siz®d_Copy  (Unit_To_^Copy  ;  String 


B.11.  Procedure  Sized_Copy’Body 

Procedure  Slzed_Copy  is  described  in  its  comments. 
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--  Proc*dur«  to  copy  a  apaciflod  fll«/  choc]clng  tha  slza  of  tha  diractory  bafora 

—  tha  fila  is  copiad  and  aftar  tha  flla  is  coplad,  in  ordar  to  datarmina  tha 

—  amount  of  spaca  tha  fila  and  its  diractory-laval  information  consumas . 


with  Profila,  Tiniing_Log/  Siza_Of,  Library; 
procadura  Sizad^Copy  (Unit_To_Copy  :  String  is 

Library's iza_Bafora_Copy  :  Natural  0;  —  Siza  of  diractory  in  bytas 

—  bafora  fila  addad. 

Llbrary_Siza_Aftar_Copy  :  Natural  0;  —  Siza  of  diractory  in  bytas 

—  aftar  fila  addad. 

bagin 

—  Gat  siza  of  diractory. 

Library_Siza_Bafora__Copy  :■  SizajOf  ("[]"); 

—  Sand  blank  lina  to  log  fila  indicatad  in  fila  raad  by 
—  Timing_Log .  ratriava_currant_log_naina . 

Tlming_Log .  J^pand_Lina ; 

—  Racord  nama  of  fila  baing  copiad. 

Tiining_Log.Appand_Lina  ("Bafora  copying  "  &  Unit_To_Copy)  ; 

—  Racord  siza  of  diractory  bafora  fila  copiad  to  it. 

Timing_Log.Appand_Lina  ("library  siza  is  "  &  Intagar' Zmaga 

(Library_Siza_Bafora_Copy)  )  ; 

--  Copy  tha  spacifiad  fila. 

Library. Copy  (From  *>  Dnit_To_Copy, 

To  ->  "[]", 

Racursiva  *>  Trua, 

Rasponsa  b>  Prof 11a. Gat, 

Copy_Links  ■>  Trua, 

Options  ->  ""); 

—  Balow  is  tha  copy  into  coosnand  as  it  was  ixnplamantad  for  Oparating 
—  Systam  Varsion  Gamma;  tha  abova  was  ioplamantad  for  Oparating  Systam 
--  Varsion  Dalta. 

—  Library .  Copy_Into 
—  (Existing  *>  Unit_To_Copy, 

—  Naw^Contaxt  *>  Library  .Cur  ran  t_Imaga,  Bafora  *>  "", 

—  Racursiva  >■>  Trua,  Rasponsa  «>  Profila.Gat, 

—  Copy^Links  ■>  Trua)  ; 

Maasura  diractory  siza  with  tha  naw  fila. 

Llbrary_Siza_Aftar_Copy  :■  Siza_Of  ("[]"); 

--  Racord  tha  sizas  and  thair  diffaranca. 

Timing^Log . i^pand_Lina  ("Aftar  copy  library  siza  is  " 

fi  Intagar' Imaga  (Library_Siza_Aftar_Copy) ) ; 


Timing_Log • Appand_Lina 

( "A  changa  of  "  fi  Xntagar' Imaga 

( Library_Si  za_Af  tar_Copy 


fi  "  bytas."); 


Library_Si  z  •_Ba  f  ora_Copy ) 


—  All  dona,  closa  log  fila. 
Timing_Log .  Closa^Log; 


and  Sizad_Copy; 
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B.12.  Binding  and  Using  Instrumentation  Code 

The  code  for  the  instrumented  procedures  can  be  placed  in  the  Experimenter's  home  directory  or 
placed  in  a  subdirectory  of  the  experiment  library  called  recordit.  If  the  latter  is  done,  then  a  link 
from  the  Experimenter's  home  directory  should  be  set  up  to  the  procedures  in  recordit  by  using 
the  LInks.Add  command. 

The  instrumented  procedures  may  be  bound  to  the  Rational  keyboard  by  inserting  the  following 
code  in  the  Experimenter's  home  directory  in  a  file  named  Ratlonal_commands. 

with  Viaibl«_JC«y_NaiM0 ; 

with  Finish_Coding_Zn0tru2n«ntation; 

with  Tiinad_DiractorY; 

with  Tijnad_^World; 

with  Siz*d_Copy; 

with  Tim*d_Coda; 

procadura  Rationml_Cosinanda  is 
us  a  Visibla_Kay_Nainas; 

typa  Zntant  is  (Prompt,  Exacuta,  Zntarrupt) ; 

Action  ;  Zntant; 

Kay_^l  :  Rational_Kay_Najnas; 

Kay_2  :  Rational_ICay_Nanias ; 

bagin 

casa  Action  is 

whan  Prompt  »> 

casa  ICay_l  is 

whan  S_F5  ■> 

Finish  Coding  Znstrumantation  (Both  «>  Falsa) ; 
whan  M_r5  ■> 

Tiaiad_Diractory  (DiractoryJMama  ■> 
whan  Cs_F5  ■> 

Tijnad__World  (World__Naina  ■>  "  " )  ; 
whan  F5  «> 

Sizad_Copy  (Unit_To_Copy  ■> 
whan  othars  «> 
null; 

and  casa; 

whan  Exacuta  «> 
casa  Kay_l  is 

whan  C_^F5  «> 

Timad  Coda; 
whan  othars  b> 
null; 
and  casa; 

whan  Zntarrupt  v> 
casa  Kay_2  is 

whan  othars  *«> 
null; 

and  casa; 

and  casa; 

and  Rational^Coxnmands; 

The  procedure  Ratlonal_Commands  should  be  promoted  to  coded  state  in  the  Experimenter’s 
home  directory.  Logging  out  and  logging  in  will  bind  the  instrumentation  commands  to  the  follow¬ 
ing  keys; 
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Procedure 


Key  Binding 


Timed  Code 


<Control>  <r5> 

<Shi£t>  <r5> 

<Meta>  <r5> 

<Control>  <Shi£t>  <r5> 
<r5> 


Finish_^Coding_Instrumentation 

Tiined_Direc'tory 


Timed  World 
Sized_Copy 


As  long  as  Rational_Commands  is  available  at  login  time,  the  instrumentation  procedures  will  be 
bound  to  the  listed  key. 

In  order  to  time  the  promotion  of  an  Ada  Unit,  either  place  the  cursor  in  a  window  containing  the 
image  of  the  unit,  or  select  the  unit  in  a  directory  listing  and  type: 

<Control>  <!'5> 
followed  by 

<shi£t>  <r5> 

This  will  cause  the  time  required  for  compilation  and  the  size  of  the  coded  object  to  be  recorded. 

To  time  the  creation  of  a  directory,  make  the  world  or  directory  that  is  to  contain  the  new  directory 
the  current  context.  Type: 

<Meta>  <r5> 

A  command  window  will  open,  prompting  for  Directory_Name;  supply  the  desired  name  as  the 
value  for  the  parameter  and  type: 

<Promot> 

This  causes  the  creation  of  a  directory  with  that  name  and  records  the  time  required  for  the 
operation. 

To  time  the  creation  of  a  world,  make  the  world  or  directory  that  is  to  contain  the  new  world  the 
current  context.  Type: 

<Control>  <Shi£t>  <r5> 

A  command  window  will  open,  prompting  for  World_Name;  supply  the  desired  name  eis  the  value 
for  the  parameter  and  type: 

<Promot> 

This  causes  the  creation  of  a  world  with  that  name  emd  records  the  time  required  for  the  opera¬ 
tion. 

To  copy  an  object  and  determine  its  size,  type: 

<r5> 

A  command  window  will  open,  prompting  for  Unit_To_Copy:  supply  the  name  of  the  unit  to  be 
copied,  and  type: 

<Promot> 

This  will  copy  the  named  object  to  the  current  context  and  log  the  amount  of  disk  space  used  by 
the  object  in  the  current  context. 
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Appendix  C:  ACEC  Suite  Timing  Harnesses 

The  following  routines  must  be  compiled  successfully  to  run  the  ACEC  Test  Suite. 


C.1.  Package  Specification  Cpu_Time’Spec 

pac)cag*  Cpu^Tim*  la 

function  Cpu_Clock  ratum  Duration; 
and  Cpu_Tima; 


C.2.  Package  Cpu_Time’Body 

with  Calandar,  Syatam^ntllltlaa ; 

—  SyatacD  Utllltlaa  la  a  atandard  Rational  utility  pacJcaga. 

pac3ca9a  body  Cpu_Tlj&a  la 

function  Cpu_ClocX  ratum  Duration  la 
bagln 

ratum  Syataza^Utllltlaa  .Cpu; 
and  Cpu  Cloch; 

and  Cpu  Tina; 


C.3.  Specification  Harness_Many’Spec 

procadura  Hamaaa  Many; 


C.4.  Procedure  Harness_Many’Body 
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with  Twxt_Io,  CAl*ndax,  Sytftaoi^Utilitiws ,  Tim«^Utilitiwfl ,  Coxopilation, 
Profile,  'Lo^f  Library,  Filajatilitias,  Program,  Io_^Packaga; 

procadura  Bamaaa_Jbiany  i« 

—  Filaa  for  raaults  ganaratad  by  ACEC  run 
Coinp_Data_Fila  :  Taxt__^Io.rila_^Typa; 

Inatr_Data_Fila  :  Taxt_Io,Fila_Typa; 

Run_Data_rila  :  Taxt_Io.Fila_Typa; 

Total_Tima_Fila  :  Taxt_Io .  Fila_Typa; 

—  Tha  following  ara  u«ad  for  raading  namas  of  ACEC  program 
Sourca_Fila  :  TaJct_Io.Fila_Typa; 

Taat_Naffla  :  String  (1  . .  7) ; 

Laat  :  Natural; 


—  Varioua  diractory-dapandant  hardwirad  namas 

—  Sourca  World  contains  tha  Ada  objacts  coisprising 

—  tha  ACEC  banchmark  tasts . 

Sourca_JWorld  :  constant  String  ”  lusars  .  0;g7en/ndnfor.  acac2  " ; 

---  List_^of_JLCZC_^Programs  is  a  taxt  fila  containing  tha  namas  of 

—  tha  Ada  objacts  that  con^risa  tha  ACEC  banchmarks . 

List_^Of_jXcac__Programs  :  constant  String  :■  Souroa_World  fi  " . acac_^list"; 
procadura  Bamass  (Tast_^Fila  :  in  Io__Packaga.Nama_^Typa)  is  sapaxata; 
bagin 

--  Craata  tha  logging  filas 

Taxt_Io .  Craata  (Fila  «>  Coix:p_^Data_^Fila, 

Moda  m>  Taxt^Io  .Out__Fila, 

Nama  «>  ”  !  usars  .  BXporimontBr.  acac2  .  C_data" , 

Form  ->  "")  ; 

Taxt_^Io. Craata  (Fila  b>  lnstr__Data_^Fila, 

Moda  ■>  Taxt^Io  .Out__Fila, 

Naina  «>  ”  ! usars  .  BXpBrimBntBf^cmcl .  I_jdata” , 

Form  -> 


Taxt^Io .Closa  (Fila  «>  Instr  Data  Fila); 


Taxt  lo . Craata 


Taxt  lo . Craata 


(Fila  «> 
Moda  B> 
Nama  «> 

Form  ■> 

(Fila  -> 
Moda  B> 

Nama  ■> 

Form  K> 


Run_^Data_^Fi  la , 

Taxt^Io .  Out_J*ila, 

”  I  usars  .  BXpBfimBntsr.  acac2  .  R_data" , 

Tot  al_Tima_ri  la , 

Taxt_Io .  Out_Fi  la , 

”  !  usars .  BXpBrifTIBntBr.  acac2  .  Total_Tima_^Data” , 

H«); 


—  Opan  fila  containing  tast  procadura  namas . 
Taxt^Io.Opan  (Fila  ■>  Sourca_Fila, 

Moda  ■>  Taxt_Io.In_rila, 

Nama  «>  List_Of_Acac_Programs, 
Form  -> 


Taxt_Io .  Put_Lina  (Total_Tima_Fila, 

"ACEC  run  bagin s  at  "  fi  TdLma_J7tilitias  .  Xmaga 

(Tima_^Utilitias  .Gat^Tima)  )  ; 

whila  not  Taxt_^Io . End_jOf_Fila  (Sourca^Fila)  loop 

Taxt_^Io .  Gat^^Lina  (Sourca^Fila,  Tast_Nama,  Last); 

Bamass  (Tast^Nama  (1  .  .  Last) ) ; 
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•nd  loop; 


T*xt_Io .  Put_Lino  (Total_Timo_Filo , 

"ACEC  run  anda  at  **  fi  Tima^Utilitiaa .  Iioaga 

(Tima  Utilltiaa . Gat  Tima)); 


Taxt_Io .  Cloaa  (Fila  •■>  Sourca_Fila)  ; 

Taxt^Io. Cloaa  (Fila  »>  Coix5>^Data^Fila) ; 

Taxt_Io . Cloaa  (Fila  «>  Run_Data_Fila) ; 

Taxt_Io.Clo»a  (Fila  «>  Total_Tima_Fila)  ; 

Taxt^Io.Put  ('*X11  taata  hava  baan  aiibmittad  for  tasting**); 


axcaption 

whan  othara  «> 

—  Sava  raaulta . 

Taxt^Io . Cloaa  (Fila  ■>  Sourca^Fila) ; 
Taxt^Io. Cloaa  (Fila  «>  Coix5>_Data_Fila) ; 
Taxt_Io.Cloaa  (Fila  «>  Run_Data_Fila) ; 


Log  daath  point. 

Taxt_Io ,  Put_Lina  (Total_Tiiaa_Fila , 

**Run  diad  on  "  £  Taat  Kama  (1  .  .  Last)  ) ; 


Taxt_^Io .  Put_Lina  (Total_Tima^Fila , 

**ACEC  run  anda  at  **  £  Tima_Utilitiaa .  Imaga 

(Tima  Utilitiaa .Gat  Tima) ) ; 


Taxt_Io  .Cloaa  (Fila  ->  Total_Tima_Fila)  ; 

—  Kotify  Initiator  of  ACEC  run. 

Taxt  lo.Put  Lina 


Taxt__^Io .  Put_^Lina 
( **  ++-HHH*+-hHhHH- 
Taxt  lo.Put  Lina 


KABOOM!  1  I 


and  Hamaaa_Many; 


C.5.  Harness  (Source  State  to  Coded  State) 

The  following  is  the  Ada  separate  needed  to  compile  the  ACEC  tests,  already  in  Rational  source 
state  to  Rational  coded  state.  This  version  of  Harness  also  records  link  and  load  time  as  a  part 
of  program  execution  time. 
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with  Zo_Exc«ptlons,  Dir*ctoz:y_Tool0; 
us*  Dlr^ctory^Tools; 

■*p*rat*  (Ham*ss^M*ny) 

proc*dur*  Ham*ss  (T*st_Fil*  :  in  Zo_Packag*.Kaiii*_Typ*)  is 

subtyp*  Cons train*d_Durat ion  is  Duration  dalta  0.01; 

Taar  :  Calandar .  Yaar_Nu2nbar; 

Month  :  Calandar.Month_Muznbar; 

Day  :  Calandar .  Day_Nuiabar; 

Bagin^Tima  :  Calandar . Day^Durat ion ; 

End^Tizna  :  Calandar. Day_Duration; 

Total^Elapsad^Tina  :  Calandar .  Day_Duration ; 

Bag_Cpu^Tima  :  Constrainad_Duration; 

End^Cpu^Tixna  :  Const rai nad_Durat ion; 

Total^Cpu_Tima  :  Constrainad_Duratlon; 

—  Tha  softwara  adds  no  consnants  to  Compilation,  Run_Tima  or 
—  Znstrumantation  data  racords. 

Coznmant^Width  :  constant  Natural  0; 

Commants  :  constant  String  (1  .  .  Comraant^Width ) 

(othars  ■>  '  '  ) ; 

Compilation^Data  ; 

Zo^PacJcaga .  Coapi lat i on^Raoo rd^Typa  ( Cocimant_Wi dth ) ; 

Run^Tima_Data  : 

Zo^Packaga .  Run^T ima_Racord^Typa  ( Commant^Wi dth )  ; 

—  A  bug  in  tha  Rational  Environmant  pravants  a  procadura  that  conpilas 

—  an  Ada  objact  from  maasuring  its  siza.  Wa  tharafora  ratum  an 

—  arbitrary  valua  until  tha  bug  in  tha  Rational  Environmant  is  fixad. 
function  Tha_Ob j ac t_Coda_S i za_0f 

(Tast^Fila  :  in  Zo^PacJcaga  .Nama_Typa)  ratum  Natural  is 
Obj  :  Objact . Handla  im  Naming.Rasolution  (Tast^Fila  &  "'body"); 
bagin 

ratum  Natural  (Statistics .  Ob  jaot_Slza  (Obj)  /  8); 
and  Tha^jOb  j  act^Coda^S  i  a:  a^Of ; 


bagin 

—  staga  1:  Racording  Compilation  and  Link  Tima 

—  racord  tha  currant  al^sad  and  CPU  timas  bafora  compilation  -- 
Calandar . Split  (Calandar . Clock,  Yaar,  Month,  Day,  Bagin^Tima) ; 

Bag_Cpu_Tima  :  ■  Sy s t am_JJt i  1  i t i as  .  Cpu ; 

--  compila  tha  tast  +  racord  and  timas  — 

Compilation.Promota  (Unit  v>  *  ! usars .  acac2  .  *  &  Tast_Fila, 

Scopa  ^■>  Compilation. Subuni ts_Too, 

Goal  «>  Compilation . Codad, 

Limit  aB>  Compilation. Sama_Horld, 

Effort_Only  ->  Falsa, 

Rasponsa  «>  Prof 11a . Gat) ; 

End^Cpu^Tima  Systam^Utilitlas . Cpu; 

Calandar . Split  (Calandar . Clock,  Yaar,  Month,  Day,  End_Tima) ; 

—  cal cu lata  tha  alapsad  timas  (in  hundradths  of  saconds)  — 

Total^Cpu_jrima  :*■  End^Cpu__Tima  -  Bag_Cpu^Tima ; 

Total_Elapsad_Tima  End_Tima  -  Bagin_Tima; 

—  put  tha  compilation  statistics  in  tha  output  racord  — 
CompilationJData  :m 
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(CocBQ«nt__Width,  Total_El*p«#d_TiM,  Total_Cpu_Tijn«, 

Th«_Ob  j  •ct_Cod#_S i  z«__Of  ( T« « t_Fi  1  • )  , 

CoTcmmntm ) ; 

Io_Pac}cmgtt .  Put  (Fil*  »>  Conip_Data_Filtt, 

Valua  «>  Conipllation_Data)  ; 

--  ataga  2:  Racording  Exacution  Tima  -- 

--  racord  tha  currant  alapaad  and  CPU  timaa  bafora  axacution  — 
Calandar. Spilt  (Calandar. Clock,  Yaar,  Month,  Day,  Bagin^Tima) ; 
Bag_Cpu_Tiiiia  Syatam^Utilltiaa  .  Cpu; 

—  axacuta  taat  +  racord  and  timaa-- 

Program.Run  (S  v>  Taat^Fila,  Contaxt  v>  ** ! ua ara  .  dXperT/ridnfdr.  acac2 " )  ; 
End_Cpu_Tima  Syatam^Utilltlaa . Cpu; 

Calandar.  Split  (Calandar.  Clock,  Yaar,  Month,  Day,  End_Tisia}  ; 


—  calculata  tha  alapaad  timaa  (in  hundradtha  of  aaconda) 
Total_Cpu_Tima  End_Cpu_Tima  -  Bag_Cpu_Tima; 

Total_Elapaad_Tima  End_Tiina  -  Bagin_Tima; 

--  put  tha  runtima  atatiatica  in  ona  output  racord  — 

Run^T  ima^Dat  a  :  «■ 

(Connaant^Width,  Taat^Fila,  Total_Elapaadj_Tima, 

Total_Cpu_Tima,  512,  512,  ConBoanta)  ; 

Io_Pac]caga .  Put  (Run_Data_Fila,  Run_Tiina_Data)  ; 

ataga  3:  Appand  Inatrumantation  Statiatica  to 
In  a  t  ruznan  t  at  i  on_St  at  ia  t  i  ca_F  il  a  ; 

Fila_Utilitiaa  .Appand  (Sourca  "  tuaara  .  experimenter.  aoac2  .  Inatr" , 

Targat  «>  **  I  uaara  .  experimenter.  acac2 . 1_Data** )  ; 


and  Hamaaa; 


C.6.  Harness  (Text  File  to  Loaded  Main  Programs) 

This  version  of  the  Ada  separate  compiles  the  ACEC  test  suite  programs  from  ASCII  file  state  to 
Rational  loaded  main  programs.  It  counts  compilation  time  as  time  to  promote  from  text  file  to 
coded  state  and  time  to  load.  Runtime  represents  the  time  to  execute  the  already  loaded  main 
progreim.  (Each  ACEC  test  program  is  a  main  program.) 


CMU/SEI-88-TR-21 


187 


with  Io_£xc«ption« ,  DirwctoryJIools; 

Mmm  Direct ory^Tools; 

••parat«  ( Hamas  «_Man7) 

procadura  Bamass  (Tast^Fila  :  in  Io^Packaga.Nama_Typa)  is 

subtypa  Cons trainad_Durat ion  is  Duration  dalta  0.01; 

Yaar  :  Calandar. Yaar_Nuznbar; 

Month  :  Calandar.M6nth_Nuxnbar; 

Day  :  Calandar .  Day_Numba  r ; 

Bagin^Tima  :  Calandar. Day_Duration; 

End^Tima  :  Calandar  .Day^Dur  at  ion; 

Total_Elapsad_Tima  :  Calandar .Day_Du rat ion; 

Bag_Cpu_Tima  :  Constrainad_Duration; 

End^Cpu^Tima  :  Cons trainad_Durat ion; 

Total_Cpu_Tiina  :  Cons trainad^Durat ion; 

—  Tha  softwara  adds  no  ooixsxiants  to  Compilation,  Run_Tizaa,  or 
--  Instrumantation  data  racords . 

Connnant_Width  :  constant  Natural  0; 

Connnants  :  constant  String  (1  .  .  Coinznant_Width) 

(othars  ■>  '  ' )  ; 

Compilation^Data  : 

Io_Packaga .  Coiopilation_Racord_Typa  (Coirsnant_Width)  ; 

Run_Tiina_Data  ; 

lo^Packaga .  Run_T ima_Racord_Typa  ( Conaxiant^Width )  ; 

--  A  bug  in  tha  Rational  Environmant  pravants  a  procadura  that  comp i las 
—  an  Ada  objact  from  maasuring  its  siza.  Wa  tharafora  ratum  an 
--  arbitrary  valua  until  tha  bug  in  tha  Rational  Environmant  is  fixad. 
function  Tha_0b j act_Coda_S i z a_Of 

(Tast_Fila  :  in  Io_Packaga  .Nama_Typa)  ratum  Natural  is 
Obj  ;  Ob jact .Bandla  Naming. Rasoluti on  (Tast^Fila  &  "'body"); 

bagin 

ratum  Natural  (Statistics .Ob jact_Siza  (Obj)  /  8); 
and  Tha_0b  j act_Coda_S i  za_Of ; 


bagin 

—  staga  1 :  Racording  Conpilation  and  Link  Tima 

—  racord  tha  currant  alapsad  and  CPU  timas  bafora  compilation 

Calandar . Split  (Calandar . Clock,  Yaar,  Month,  Day,  Bagin^Tima) ; 

Bag_Cpu_Tlma  :  >  Sy s  t am_Ut i  1  i  t i  as  .  Cpu ; 

--  coxopila  tha  tast  -f  racord  and  timas  — 

Coztpilation .  Conpila  (Fila_Nama  «> 

"  !  usars .  experimenter,  acac .  "  &  Tast^Fila, 
Library  ^■>  "!  usars .  experimenter,  acac3  " , 

Goal  Compilation .  Codad, 

List  ■>  Falsa, 

Sou rca_Opt ions  »>  " " , 

Limit  ^■>  Conpilation .  Sama_World 
Rasponsa  Profila.Gat) ; 

Conpilation . Load  (Fila  Nama  *> 

"!  usars  .  experimenter.  acac3 .  "  & 

Tast_Fila(l. .6) , 

To  ■>  " ! usars .  experimenter,  acac4  " , 

Rasponsa  <PROFIL£>) ; 

End^Cpu^Tima  Systam_Utilitias . Cpu; 

Calandar. Split  (Calandar .Clock,  Yaar,  Month,  Day,  End^Tima) ; 
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—  calculate  tha  al^aad  tixnaa  (in  hundradtha  of  saconda) 


Total^Cpu__Tima  :■  End_Cpu^Tima  -  Bag_Cpu^Tima; 

Total_Elapaad^Tixiia  ;«  End^Tima  -  Bagin_Tixna; 

--  put  tha  coaopilatlon  atatlatica  in  tha  output  racord  -- 
Compilatlon_Data  :« 

(Coimnant_Width,  Ta»t_Fila,  Total^Elap»ad_Tima,  Total^Cpu^Tixoa, 
Tha_abjact_Coda_Sira_Of  (Taat_Fila) , 

Conmanta)  ; 

Io_Pac]caga .  Put  (Flla  »>  CoiDp^Data_Fila, 

Valua  ■>  CoiBpilation_pata)  ; 

—  ataga  2:  Racording  Exacutlon  Tima  -- 

—  racord  tha  currant  alapaad  and  CPU  timaa  bafora  axacution  -- 
Calandar.  Split  (Calandar.  Clock,  Yaar,  Month,  Day,  Bagin__Tima) ; 
Bag_Cpu_Tima  :■  Syatain__ntilitiaa  . Cpu; 

—  axacuta  taat  +  racord  and  timaa — 

Program. Run  (S  ■>  Taat^Fila,  Contaxt  ■>  "  1  uaara  .  axp&nmdnfer.  acac4  ** }  ; 
End^Cpu_Tima  :■  Syatam_Utilitiaa  ,  Cpu; 

Calandar. Split  (Calandar. Clock,  Yaar,  Month,  Day,  End^Tima) ; 


—  calculata  tha  alapaad  timaa  (in  hundradtha  of  aaconda)  -- 
Total^Cpu^Tima  End^Cpu^Tima  -  Bag_Cpu  Tima; 

Total_Elapaad_Tima  End^Tima  -  Bagin^Tizaa; 

—  put  tha  runtima  atatiatica  in  ona  output  racord  -- 
Run^Tima^Data  : ■ 

(CoiEBBant_Width,  Taat^Fila,  Total^Elapaad_Tima, 

Total_Cpu_Tima,  512,  512,  Commanta); 

Io_Packaga .Put  ( Run_Dat a_Fi  1  a ,  Run_T ima_Dat a )  ; 

—  ataga  3:  Appand  Inatrumantation  Statiatica  to 

In a t ruman t at ion^S t at i a t ic a_Fi 1 a ; 

Fila_Utilitiaa  .Appand  ( Sourca  «>  **  f  uaara  .  GXpBrim&ntBT,  acao2  .  Inatr "  , 

Targat  «>  **  1  uaara  .  &Xporim enter.  acac2 . 1_Data'* )  ,* 


and  Hamaaa; 


C.7.  Commands  to  Run  the  ACEC  Test  Suite 

The  above  procedures,  specifications,  and  either  of  the  separates  must  be  compiled  in  addition  to 
the  support  programs  provided  by  the  ACEC  Test  Suite. 

The  ACEC  Test  Suite  can  then  be  run  in  batch  mode  by  providing  the  following  command  in  a 
command  window  and  promoting  the  command  to  execute. 

Program.Run^Job  (S  >>  "Hamaaa**, 

Dabug  «>  Falaa, 

Contaxt  "  f  Uaara .  experimenter. Xcmc2  " , 

Aftar  «>  0 . 0, 

Optiona  ■>  "Output  Run^Job^Output ;  Error  ■:  Run_Job_Error" , 

Raaponaa  ■i>  "<PROFIL£>" )  ; 

Note  that  a  value  of  positive  seconds  may  be  provided  for  the  After  parameter.  The  Harness 
would  then  not  start  executing  until  after  that  number  of  seconds  had  elapsed  since  the  command 
window  was  promoted. 
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